Best Practice when Migrating Domains

“Help! I’m a Systems Administrator managing PaperCut, and we’ll soon be moving all of our servers and applications to a new Active Directory domain. Does PaperCut have any advice?” Migrating an Active Directory domain is one of the biggest projects you can undertake as a sysadmin, and it’s important to get things right the first time around to keep your users happy. Fortunately, we hear all the time from customers who have successfully moved their print infrastructure and PaperCut server to a new domain without issue. You might have a few questions like… Should we just join the server to the domain, or should we set up a completely new server? What will happen to our user accounts? How can we break the process down into smaller steps to make the change as seamless as possible? After hearing back from our customers about their domain migration experiences, we have some advice about how to ensure as smooth a transition as possible. Stick with the same PaperCut server While you could set up a completely new PaperCut server in the new domain, it probably will be easiest to stick with the original server and simply join it to the new domain. There are several reasons why we recommend keeping the same server during a migration. Your print infrastructure (such as logon scripts, mapped printers, Group Policies) is likely pointed at a specific print server and it may be challenging to move all of these pieces. You may have PaperCut configured to communicate with an external Payment Gateway, sometimes with port forwarding and other rules configured on the firewall to ensure transactions occur successfully. If you are an MF customer, there may be copiers running the PaperCut embedded application which are configured to talk to your PaperCut server. For these reasons, Migrating PaperCut to a new server can be a project in its own right. For these reasons, consider doing this at a different time as a separate task. Check if the usernames will be changing Fortunately, PaperCut imports user accounts without a domain name, so the impact will be very little so long as the usernames will be the same in the new domain. However, if the usernames are changing during the migration (for example from firstname.lastname to f.lastname) then you will want to use our username alias feature to make sure that two accounts with different usernames are not created for the same person. More info here: https://www.papercut.com/kb/Main/UserNameAliasing Check if the Groups or OU structure will be changing In PaperCut Group membership can affect several other details in PaperCut such as which Filters and Restrictions apply, Quota Scheduling, as well as determining who has Admin Rights or access to Scan Actions. So if the Active Directory Groups are staying the same then you shouldn’t have a problem. However, if these groups are changing we suggest breaking down the change to new group names as a step change. You can either recreate the old groups in your new domain before migrating the PaperCut server, or create the new groups in your old domain, import these into PaperCut then configure your groups as needed. Some customers have let us know that after moving domains they see an error like this when attempting to sync: ERROR occurred: ERROR finding OU members (-2147023541): Automation ERROR The specified domain either does not exist or could not be contacted. (-2147023541) The solution is to remove those groups from the Selected list and then add in the correct groups(they may be named exactly the same, but will instead be tied to the new domain change). Double check which Sync source is configured A setting that needs to be considered when migrating domain’s is the User/Group Sync feature. If you are using Active Directory as the primary sync source, the change should be automatic. Papercut will reach out to the Domain Controller just as it did on the old domain and provided it is able to connect, we should see the User/Group Sync continue to function as expected. If you have ‘LDAP’ set as the Primary sync source, the connection information will be statically entered and will be outdated when we move to the new domain. In the example above, we see Papercut connecting to a ‘papercutpdx.com’ domain. If we migrated to a different domain without changing this information, we would see the User/Group Sync function fail the next time it runs. To resolve this, simply update the connection information (Base DN, Admin DN, and LDAP Server Address if the IP of the LDAP server is changing) with information that matches your new domain. Ask whether PaperCut is running as a Service Account By default, the Papercut Application service will run under the ‘System’ account in Windows but if your organization has configured PaperCut to run as a domain user or Service Account, it may no longer be valid when the domain is migrated causing the Application Service to not start correctly. To verify if this is set properly, navigate to Services.msc in Windows and scroll down to the “Papercut Application Service”, right-click, and enter the ‘Properties’ for this service. Click on the ‘Log on’ tab and you will see an interface similar to what can be seen here: If ‘Local System account’ is selected, then there should be no changes necessary for the Papercut service to start correctly on the new domain. If ‘This account’ is selected, you will want to be sure to update this service account to an account on the new domain that has the proper permissions. Still have questions? Let us know! We love chatting about what’s going on under the hood. Feel free to leave a comment below or visit our Support Portal for further assistance.