How to upgrade or migrate Active Directory server

A quick walkthrough on how to upgrade or migrate an Active Directory Server.

In this guide, the old server is Windows Server 2008 R2 Standard, and the new server is Windows Server 2016 Essentials.

This guide should work on other Windows Server version as the concept would be pretty much the same.

Firstly, we would install Active Directory (AD) role on the new server.

If AD role can’t be installed, we can safely remove the Active Directory Certificate Services first.

The we would join the new server to the domain.

Then type this on the new domain controller:

C:\Windows\system32> netdom query fsmo
Schema master ws-2008-r2-std.saputra.local
Domain naming master ws-2008-r2-std.saputra.local
PDC ws-2008-r2-std.saputra.local
RID pool manager ws-2008-r2-std.saputra.local
Infrastructure master ws-2008-r2-std.saputra.local
The command completed successfully.

That means all of the domain role still being handled by the old server.

Let’s go to Active Directory Users and Computers
Right click on saputra.local and select Operations Masters
Change operation masters to new server for all RID, PDC, and Infrastructure

After we changed three roles above, the condition should be like this:

C:\Windows\system32> netdom query fsmo
Schema master ws-2008-r2-std.saputra.local
Domain naming master ws-2008-r2-std.saputra.local
PDC ws-2016-ess.saputra.local
RID pool manager ws-2016-ess.saputra.local
Infrastructure master ws-2016-ess.saputra.local
The command completed successfully.

Go to Active Directory Domains and Trusts
On the left pane, right click on Active Directory Domains and Trusts
Select Operations Masters (there’s Raise Forest Functional Level as well, completely optional)

And the role should now become like this:

C:\Windows\system32> netdom query fsmo
Schema master ws-2008-r2-std.saputra.local
Domain naming master ws-2016-ess.saputra.local
PDC ws-2016-ess.saputra.local
RID pool manager ws-2016-ess.saputra.local
Infrastructure master ws-2016-ess.saputra.local
The command completed successfully.

To transfer the last role, type:

C:\Windows\system32> regsvr32 schmmgmt.dll

Then:

C:\Windows\system32> mmc.exe

Load snap-in Active Directory Schema
It will then connect to the old AD server first
Right click ‘Connect to Schema Operations Master’ and select the new server
Then select Operations Master and change the role with the new server:

C:\Windows\system32> netdom query fsmo
Schema master ws-2016-ess.saputra.local
Domain naming master ws-2016-ess.saputra.local
PDC ws-2016-ess.saputra.local
RID pool manager ws-2016-ess.saputra.local
Infrastructure master ws-2016-ess.saputra.local
The command completed successfully.
Demoting old server

Obviously, go to the old server;
Use dcpromo.exe, it will say AD is a Global Catalog server;
Go to Active Directory Users and Computers (this can be done from either new server or old server);
Expand the domain and select Domain Controllers;
Select the old server and click on NTDS Settings;
Untick Global Catalog;

And now we should be able to demote the old server.

If you have any questions or comments, please write down below and I would happy to answer 🙂

 

Migrating a Mac Local User to a Network User

I’ve seen several places where a smaller company has been integrated into a large company, or where the number of Macs in the company has grown, and now you want those users to have their machines and login managed under the network directory system, be that Open Directory or Active Directory. The most frequent issue with this is that a user has an existing home directory that they’ve been working with and want to be able to bring this over to the new environment. This is a walk-through of how to make that process as painless as possible.

Note: These instructions are based around a 10.5.x client OS. 10.5 uses plist files for user records, where 10.4 used Netinfo. The same theory applies to 10.4, but the method is different, in that the user must be removed from Netinfo.

We’re going to start this assuming that we have already successfully bound our client machine to the existing directory authentication structure. What you may notice here, is that even though your user account exists on the directory server, you may not be able to login with it’s credentials. This is probably because the shortname of both your local user account and your network user account are the same. The search policy for Directory Services on the client will always look to the local machine for authentication first.

You may need to create a new administrative user at this point as you will need to be logged into the client as some user other than the user that you are planning to migrate. Using this alternate user, use the Terminal to navigate to /var/db/dslocal/nodes/Default/users

macmini:~ admin$ sudo -s
Password:
bash-3.2# cd /var/db/dslocal/nodes/Default/users/

We had to use sudo before this command as the files within the Default node is only viewable by the root user.

From here we’re going to move the plist file for the user we want to migrate. I’m only moving, rather than removing to preserve the file in case I want to go back to the local user for any reason. Once you’ve tested a successful login at the end of this process you can delete the file we’re moving into /Users/Shared/.

mv andy.plist /Users/Shared/

You’ll notice if you run an “id” command on the user you just moved the local information will still show up.

bash-3.2# id andy
uid=502(andy) gid=20(staff) groups=20(staff),103(com.apple.sharepoint.group.3),98(_lpadmin),101(com.apple.sharepoint.group.1),102(com.apple.sharepoint.group.2)

We need to restart the DirectoryService process before our change takes affect.

bash-3.2# killall DirectoryService
bash-3.2# id andy
uid=1026(andy) gid=20(staff) groups=20(staff),103(com.apple.sharepoint.group.3),98(_lpadmin),101(com.apple.sharepoint.group.1),81(_appserveradm),1030(all),1027(vpn),102(com.apple.sharepoint.group.2),79(_appserverusr),80(admin)

You’ll notice that the information coming back from the “id” is now from the directory server, and not the local user info, however, if we try to log in at this point the ownership of the files in the home directory will be incorrect. To fix this, we’ll run a recursive chown on the user home directory.

bash-3.2# chown -R andy /Users/andy

Your user is now ready to log in with their directory username and password, and their home directory will remain the same.

Manual Delta & Full Sync between AD & Office 365

How to do manual synchronise between Active Directory DIRSYNC and Office 365 using PowerShell?

Open up Windows PowerShell, and then invoke the following command:

FinishedPS C:\Program Files\Microsoft Azure AD Sync\Bin> .\DirectorySyncClientCmd.exe delta
saputra.local

Initializing
Importing………………
Synchronizing from all Sources.
Synchronizing from Target.
Exporting to Target………………..
Exporting to all Sources
FinishedPS C:\Program Files\Microsoft Azure AD Sync\Bin> .\DirectorySyncClientCmd.exe initial
saputra.local

Initializing
Importing…….
Synchronizing from all Sources
Synchronizing from Target.
Exporting to Target………………….
Exporting to all Sources
FinishedPS C:\Program Files\Microsoft Azure AD Sync\Bin>

‘Delta’ is for delta sync, while ‘Initial’ will do full synchronisation.