To totally unlock this section you need to Log-in
Usually, on most modern environments, the fastest way to build a larger virtual environment (either test or production), is to install or prepare one VM and then clone it. This process is not the same for every environment. Additionally, it depends on the mechanism of the VM cloning process, and hypervisor used.
Additionally, every computer in an Active Directory (Microsoft) domain has its own identification string. This identification is not its name. The computer name is useful for us. Moreover, this identifier must be unique in the domain.
On the machine level, every computer is identified by a unique value; named Security ID or SID. SID is calculated in the process of the installation of every Windows machine. Whether the computer is part of the workgroup (or it’s just a stand-alone computer), the value of SID is not crucial.
Whenever we need to build the Active Directory domain, we need to have machines with different SIDs. Even more, when we build our virtual lab in Oracle VirtualBox (VBox), or even in VMware, the clones will always keep the old SID from the original machine.
Adding VM to the domain
For this scenario we need at least two servers. This is not a problem specifically with VirtualBox VMs. We prepare two VMs. The first became the AD domain controller server. When we try to add the second machine into the domain, we could face the error. The SID of the domain (i.e. the domain controller) is the same as the SID of this VM.
If we check this message, we will see that we have the solution right in front of us. We need to run the tool named SysPrep. The SysPrep (or System Preparation) tool should sounds familiar to every seasoned Windows admin.
Yes, with the SysPrep tool we can delete the SID and all other settings, leaving the machine in an uninitialized state. The machine will be initialized on its first run. This mechanism allows admins to clone both physical and virtual machines easily.
The SysPrep tool
The SysPrep tool is located on the path %systemroot%\System32\SysPrep. In most cases, this is equivalent to the path C:\Windows\System32\sysprep (usually, all cases). You have this tool in the Windows 7 and later workstations, GUI versions of Windows Server, and also on the Core version.
Locate the SysPrep tool and run it as administrator. After a while, the application window will appear on the screen. In the Core version just type the command. The rest is the same.
Leave the System Cleanup Action drop-down menu on the option Enter System Out-of-Box Experience (OOBE). We want to clean all personalized settings of the machine.
However, we want to return this machine to an uninitialized state, as we just installed it. Therefore, tick the checkbox named Generalize.
The third option depends on your preferences. If you only need to clear the state on this machine, you will probably need to reboot it and continue to work. However, when you want to reset your master machine, you will need to shut it down after this process finished.
In this scenario, we only need reinitialize this VM and we click on the button [ OK ]. The SysPrep tool will start. The rest of the process is automated and you can’t cancel it.
The first phase is the cleanup phase, where settings will be cleared. The second phase will perform generalization (re-initialization) of the machine.
After a while, our machine will reboot.
Re-birth
Our VM for the second server rebooted and started up. The first screen is usual for the Windows Server 2012 R2 boot sequence; then came the pleasant surprise.
Windows Server discovered that its device database is empty, so it started to search; the system now needs to detect all existing hardware.
One significant advantage here is that we may have a larger pool of device drivers, especially those for VirtualBox integration. SysPrep will delete personalization and settings, but not the files on the disk.
When server finished with initialization (during which you need to specify again the admin’s password), we can proceed to join the domain.
Server is in the domain
Now our server is completely reinitialized, as if it’s just been installed. That also means that any previously installed application needs to be reinstalled.
We again change the server name to SERVER02 and joined it to the domain. Then we proceed to the test scenario.
As you can see, this small yet powerful tool can be very useful. You should perform generalization of the VM template after the installation. Then, every new VM based on that template will be different from any others. Although you need a few minutes more to setup every new VM, that short time will be of great benefit later.
Get Computer SID in Active Directory
On Active Directory environments, using Powershell, is really simple to get a complete list on SIDs of Computer objects. Here is a working example (needs to run or directly on a Domain Controller, with administrative privileges, or using Active Directory Powershell Module):
Get-ADComputer -Filter * | Select DNSHostName, ObjectClass, SID
Get Machine Computer SID (VBScript)
To get a Computer SID (Machine SID) using VBScript code we can use the WMI interfaces to query this info directly from the system:
strComputer = "WORKSTATION" strUsername = "Administrator" Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2") Set objAccount = objWMIService.Get("Win32_UserAccount.Name='" & strUsername & "',Domain='" & strComputer & "'") WScript.Echo "Administrator account SID: " & objAccount.SID WScript.Echo "Computer's SID: " & Left(objAccount.SID, Len(objAccount.SID) - 4)
Take note that we need to specify a local account to get also the Computer SID. Remember that a local Computer SID is different based on the authority in which we are retriving this info, Domain and/or Workstation. Domain systems have two different Computer SIDs.
Get Machine Computer SID (VBScript)
The following is a similar approach in Powershell to get a SID from the local machine:
function Get-Sid { Param ( $DSIdentity ) $ID = new-object System.Security.Principal.NTAccount($DSIdentity) $TempID = $ID.Translate( [System.Security.Principal.SecurityIdentifier] ).toString() $MachineID = $TempID.SubString(0, $TempID.Length - 4) Return $MachineID } $MID = get-sid "WORKSTATION\Administrator"
PSGetSID (SysInternals)
PsGetsid (a command-line tool by Mark Russinovich) allows you to translate SIDs to their display name and vice versa. It works on builtin accounts, domain accounts, and local accounts.
This tool also works remotely. However, there are two issues with the tool: the first is that it is a bit slower than querying AD DS (Active Directory). The second is that it returns a string that must be parsed if we want to use the information in other Powershell cmdlets. The following is a direct download hosted on Heelpbook.net. The original URL is the following: https://docs.microsoft.com/en-us/sysinternals/downloads/psgetsid.
PSGetSID (Get Microsoft Accounts SID)