UPromote Operation
This page contains detailed technical information on the operation of UPromote. It is for technical experts who want to know about the inner details of how UPromote works.
You do not need to know this information in order to run UPromote.
Operation
UPromote runs as a wizard application. It will ask you a series of questions, culminating in a final "Finish" button. UPromote makes no changes to your computer until you press the Finish button. When you press the Finish button UPromote will perform all of its operations and reboot your computer two times.
UPromote will take anywhere from 5 minutes to an hour to complete. A large number of groups (more than 2000) or a large number of files (more than 200000) may take more than an hour. Small memory (under 128 MB) will also slow it down. If the computer has small memory you can speed up the operation by stopping memory-hogging services such as SQL Server or Exchange.
When the message "Operation complete" appears, you can uninstall UPromote.
Error Checks
While showing the wizard pages UPromote will perform several checks of your computer looking for possible errors that will prevent it from running successfully. These error checks are passive and do not modify your computer in any way.
The error checks include the following,
- Logon account has Administrator privileges
- Computer can contact the PDC and logon with Administrator
- Computer and PDC are not running Novell Directory Services (NDS)
- Not running Terminal Server
- Not running Small Business Server
- Running SRV and KS services
- No buggy Compaq RAID disk controller
- No Service Pack conflict
- No buggy Internet Explorer 4.0 Protected Storage
- At least 200 megabytes of free disk space on the system drive
- At least 8 megabytes of free space in the registry
- Domain name is not already in use (if promoting PDC)
- No member computers or BDCs remain (if demoting PDC)
- No Trust Relationships remain (if demoting PDC)
You can override most of the error checks by appending the parameter -OVERRIDE to PROMOTE.EXE
- Press Start -> Run
- Type "C:\Program Files\UPromote\PROMOTE.EXE" -OVERRIDE
Note the explicit quotation marks ("") - Press OK
Note: Override of error checks is not recommended. We cannot provide you with support if you encounter a problem while ignoring the error checks.
License Activation Code
Without a license activation code, UPromote runs in Demonstration Mode. The Finish button is disabled.
When you buy a license activation code and type it in, UPromote will unlock the Finish button. If you purchased a single computer license, UPromote will check that the license activation code matches the name of the computer.
Execution
When you press the Finish button UPromote will start converting your computer. The exact steps depend on whether you are creating a PDC, a BDC, or a standalone server.
The main difference between a standalone server and a domain controller (DC) is that a DC runs the NETLOGON service. The NETLOGON service authenticates passwords of users in the domain.
Primary Domain Controller
To create a Primary Domain Controller (PDC) UPromote does the following:
- Create the groups Domain Admins, Domain Users, Domain Guests, Account Operators, Server Operators, and Print Operators.
- Enable the NETLOGON service and the RPCLOCATOR service.
- Publish %systemroot%\repl\import\scripts as the file share NETLOGON.
- Publish %systemroot%\repl\export as the file share REPL$.
- Move users from the group Administrators to the group Domain Admins.
- Move users from the group Users to the group Domain Users.
- Write the domain name to the registry.
- Change the domain role to from SERVER to PRIMARY. (Type NET ACCOUNTS to view.)
- Enable the domain logon dropbox in WINLOGON.
Backup Domain Controller
To create a Backup Domain Controller (BDC) UPromote executes the same steps as described above. It also executes the following additional steps:
- Create the machine account on the PDC. (If running Active Directory, UPromote will give you instructions on how to create the machine account manually.)
- Roll back the SAM serial number to 1. This prepares the BDC to replicate a fresh copy of the SAM from the PDC.
- Roll back the SAM timestamp to the year 1980.
- Set a registry key to force full (non-partial) replication of the SAM on the next reboot.
- Change the domain role from SERVER to BACKUP.
- Change the Security ID (SID) prefix to match the PDC.
Standalone Server
To create a standalone server UPromote does the following:
- Disable the NETLOGON service and the RPCLOCATOR service.
- Delete the file shares NETLOGON and REPL$.
- Delete the machine account on the PDC.
- For each user that is a member of domain global group XXX where XXX is a member of domain local group YYY, move the user to group YYY. For example, move Administrator from the global group Domain Admins to the local group Administrators. Move regular users from the global group Domain Users to the local group Users.
- Delete all domain global groups including Domain Admins and Domain Users.
- Create the local groups Guests and Power Users.
- Delete the domain name from the registry.
- Delete the domain SID from the registry.
- Disable the domain logon dropbox in WINLOGON.
- Change the domain role to SERVER.
- Put the computer in a workgroup.
- Change the Security ID (SID) prefix to a random value. This is required to prevent the computer's SID prefix from clashing with the remaining domain controllers.
These operations happen only on the local computer. For example if you are demoting a BDC, the users and groups are modified only on the BDC itself; UPromote does not modify the users and groups (nor any services or file shares) on the PDC.
Security Identifiers
A security identifier (SID) prefix is a number that uniquely identifies a computer in a network. Each member computer in a domain has a unique SID prefix.
The Primary Domain Controller shares the same SID prefix with its Backup Domain Controllers. In other words, all domain controllers in the same domain also share the same SID prefix. This makes the Primary Domain Controller interchangeable with the Backup Domain Controller.
When you promote a DC, the SID prefix must be changed to match the other DCs in the domain. Conversely when you demote a DC, the SID prefix must be changed to avoid clashing with the remaining DCs. To change the SID prefix UPromote scans the entire registry and all of the files. It changes all of the registry keys and all of the files to use the new SID prefix.
Security IDs and the Registry
UPromote does a simple search-and-replace of all instances of old SID prefix in the registry. The SID prefix is encoded in 4 different formats in various keys in the SAM and the rest of the registry. (Tools such as Norton Ghost and newsid only recognize 3 formats, which is why these tools fail when used on a domain controller.)
When UPromote finds a match it replaces the SID prefix with the new value. This simple operation has several side effects. For example, the access permissions for file shares are stored in the registry under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Shares\Security. The SIDs for the access permissions are changed just like any other SID. This is why the domain share permissions no longer work when you rejoin the computer back to the domain. As explained in the FAQ, you will need to run EXPLORER.EXE and re-enter the permissions for the domain groups to access the file shares.
The SIDs for the user accounts in HKEY_LOCAL_MACHINE\SAM are changed as well. When demoting a BDC, the result is that the user accounts become local accounts with the same names as the original domain accounts. They become distinct accounts. They are not domain accounts even through they may appear superficially to be the same. If you rejoin the same domain as a member server, most of these accounts will become redundant and you can delete them.
This can best be explained with an example. Let's say you have a BDC named B that you want to demote and then rejoin back to the same domain as a member.
Because it is a BDC, machine B has an exact copy all the user accounts on the PDC (call it machine A). Each of these accounts has a unique SID. For example the user FRED has SID S-1-5-123456-1001. When you run UPromote on machine B, the SID for FRED on B is changed to a new random SID prefix: S-1-5-7890123-1001.
The account DOM\FRED still exists unchanged on machine A. But the SID for account FRED on machine B is now S-1-5-7890123-1001. Both have the same user name but are now distinct accounts. As far as NT is concerned the two accounts are completely unrelated. B\FRED now owns \WINNT\PROFILES\FRED on machine B.
When you log on to machine B with DOM\FRED it is as if he is logging on for the first time. Machine B will search the registry key HKLM\Software\Microsoft\Windows NT\Current Version\ProfileList, looking look for a subkey with SID S-1-5-123456-1001. It doesn't find one, so it creates a new profile for DOM\FRED at \WINNT\PROFILES\FRED.000. It stores a pointer to this new profile at HKLM\Software\Microsoft\Windows NT\Current Version\ProfileList\S-1-5-123456-1001, under the value name ProfileImagePath.
Because DOM\FRED is logging on for the first time, WINLOGON.EXE on B will assign to DOM\FRED an initial profile. The new profile is copied from the Default User template at \WINNT\PROFILES\Default User\*. This is how DOM\FRED gets the initial set of icons on the desktop.
Now remember B\FRED was originally DOM\FRED, and he had all of the original icons and application settings. But because the SID was renumbered, these are now owned by B\FRED. The physical files haven't moved; they are just owned by a different account (a local account).
If you need to copy over the original icons and application settings back to DOM\FRED, log on to machine B with an unrelated account (e.g., Administrator) and type
CD \WINNT\PROFILES XCOPY FRED FRED.000 /s /e /h /k
This will copy over the icons and registry settings from B\FRED to DOM\FRED. (Note that the suffixes ".000" may vary. Inspect the registry value ProfileImagePath to determine the correct folder names for the source and destination folders.)
If you no longer need the account B\FRED you can delete it. On machine B type NET USERS FRED /DELETE.
Changing the Security ID on Disks
UPromote does a global change-and-replace of the Security ID (SID) prefix in the registry and on disk. The SID prefix in the Access Control List (ACL) of every disk file is changed to match the new SID prefix.
In practice few SIDs are changed. The vast majority of SIDs represent well known groups that have fixed values. The well known groups include Everyone, Guests, Users, Authenticated Users, Backup Operators, Administrators, and System. These groups have the same fixed SID prefix worldwide. UPromote will not change these SIDs.
Any groups that you created will have a unique SID. When you promote or demote a BDC UPromote will change the SID prefix for all of the groups that you created.
By default UPromote will select all local disks. It will scan all local disks for files that contain an ACL with the old unique SID prefix and change it to the new unique SID prefix.
Normally you can accept UPromote's defaults and simply press the Finish button. Important: There is one important exception where the unique SID prefix should not be changed. The exception applies if following conditions are all true:
- The computer is a BDC being demoted to a standalone server,
- and you intend to rejoin it back to the same domain as a member server,
- and the computer offers shared folders for access by other users in the domain.
If all of the above conditions are true, then you should consider not changing the SID on the disk(s) that contain the shared files. The reason is that the disk contains shared files that are owned by other users in the domain. If the SID prefix is changed, the users could lose access to their files. For each disk letter (D:, E:, etc.) select "Do not change these disks" on the SID ownership panel. This will leave the original domain SID prefix unchanged on those disks.
You must always change the SID on your Windows system disk (typically C:). This is required for Windows to operate properly.
If you mistakenly selected the wrong disks you can correct the problem by promoting the computer back to a BDC and then demote it again with the correct disks. When you promote the computer, select the same disk letters so that UPromote will restore the file SIDs back to their original values. Then run UPromote again to demote the BDC and select "Do not change disks" with the correct disks.
Locating a Domain Controller
The following information may help you troubleshoot problems with locating a domain controller.
When you enter your password on the member computer, it attempts to locate a DC by broadcasting a NETBIOS packet of type <1Ch>. The packet contains the name of the domain. When a DC receives the packet it will respond with its name and Internet address. The member computer will then send the logon password (in a hashed and encrypted form) to the DC for authentication. The NETLOGON service will read the password, authenticate it, and send a response to the member computer.
A member computer can also locate a DC by querying the Network Neighborhood (NN). The NN is a list of all computers on the local network. The list is maintained on a special computer called the master browser. The master browser is usually the first domain controller that booted on the network. (You can identify the master browser computer by running the console application NBTSTAT.EXE -a. The computer that responds with the record name __MSBROWSE__ is the master browser.)
The Network Neighborhood
The list of names in the Network Neighborhood will gradually expire after about an hour. To refresh the list each computer on the network periodically sends a NETBIOS broadcast packet, about once every 10 minutes. When the master browser sees these packets it will refresh the list of names in the NN. This is why the name of a DC remains in the NN for up to 60 minutes after you demote it with UPromote.
The Server Manager (SRVMGR.EXE) uses the Network Neighborhood to identify the list of DCs. This is why you must wait 60 minutes after running UPromote before SRVMGR.EXE updates its list of DCs. If SRVMGR.EXE cannot find a computer in the NN, it will ghost the icon for the DC, indicating that the DC is offline. Even if you reboot the computer as a standalone server, Server Manager will continue to show a "ghost" icon for the DC until the time expires.
Locating a DC and WINS
If your network is running a WINS server and your computer is configured as a WINS client, the steps for locating a DC are different. Instead of broadcasting a NETBIOS packet, the member computer will send a query to the WINS server. It will ask for a record that contains the name of the domain. The record must have type <1Ch>. (1C = DC, 1B = PDC). The WINS server will respond with the Internet address contained in the record. If the WINS server has more than one record, it will return one randomly. The member computer will then contact the DC as explained above.
When UPromote removes a DC, it does not remove the WINS record. UPromote cannot remove the WINS record because Microsoft does not provide a method to remove a WINS record programmatically. Therefore to remove the 1C and/or 1B record you must launch the WINS Manager and remove it manually.
WINS is also used to update the Network Neighborhood (NN). Because WINS considers a DC record to be 'important', it will cache the record for up to 7 days before deleting it. During this time the ghost DC may continue to appear in the Network Neighborhood. Member computers will continue to attempt to authenticate with the ghost DC for 7 days. After a few seconds the attempt will time out and the member computer will then attempt to authenticate with another DC. This why after using UPromote there is sometimes a short delay of a few seconds when authenticating a password. The delay goes away after 7 days.
(In rare cases the file LMHOSTS may contain the name of the DC. If the file contains a text line with #DOM, the ghost DC will be present in the NN as explained above, however it will never expire until you delete the text line from LMHOSTS with a text editor.)
Cached Passwords
If a member computer cannot locate a DC, it will attempt to authenticate the password using a local cache of the 10 most recently used passwords. The cache is stored in an encrypted form in the local registry. This is why if you demote the last DC, the orphaned member computers will still appear to be authenticating even though the DC no longer exists.
To view the list of actual domain controllers run the console utility NLTEST.EXE /DCLIST:mydomain where mydomain is the name of your domain. NLTEST is part of the NT Resource Kit.