Force Removing Active Directory from a DC

Dcpromo is the Windows 2000 and Windows Server 2003 GUI interface for promoting a server to the role of being a Domain Controller, and if is already a DC, then dcpromo will be the tool to use to demote it back to being a member server.

Dcpromo has a specific set of checks it performs before allowing the process to continue. These requirements change based on whether the server is being promoted or demoted. In this article we will deal with demoting issues.

Dcpromo might fail when trying to demote a Domain Controller in some cases. These scenarios include, for example:

 

• There are no domain controllers currently available in the parent domain when you try to demote the last domain controller in a child domain.
   
• Dcpromo cannot complete because there is a name resolution, authentication, replication engine, or AD object dependency that you cannot resolve.
   
• A DC has not replicated incoming Active Directory changes in Tombstone Lifetime (Default Tombstone Lifetime is 60 days for Windows 2000 and Windows Server 2003 DCs, and 180 days for Windows Server 2003 SP1 and R2 DCs) number of days for one or more naming contexts.

If you run Dcpromo on an existing DC to demote it and it fails because of one of the above scenarios the best thing you should do is to try to resolve the problem and then restart Dcpromo. However, if Dcpromo still fails you can still demote the DC by running Dcpromo with the /forceremoval switch, which tells the process to ignore errors. Note that the /forceremoval demotion causes the loss of any locally held changes and should be considered a last resort that you should use and only when absolutely necessary.

With /forceremoval, an administrator can forcibly remove Active Directory and roll back the system without having to contact or replicate any locally held changes to another DC in the forest.

Note: The /forceremoval switch is only supported on Windows 2000 Servers that either have SP2 with Q332199 hotfix installed on them, or with SP4, and on Windows Server 2003 servers.

Windows Server 2003 SP1 enhances the /forceremoval process. When it is run it checks to determine whether the DC hosts an operations master role (FSMO role – read my “Understanding FSMO Roles in Active Directory” article), is a Domain Name System (DNS) server, or is a global catalog server. For each of these roles, the administrator receives a popup warning that advises the administrator to take appropriate action.

RID Master warning:

PDC Emulator warning:

Infrastructure Master warning:

Naming Master warning:

Schema Master warning:

DNS Server warning:

Global Catalog Server warning:

When you force the demotion of a DC, you return the operating system to a state that is the same as the successful demotion of the last domain controller in a domain (service start values, installed services, use of a registry based SAM for the account database, computer is a member of a workgroup).

Note: In Windows 2000, the System event log identifies forcibly demoted DCs and instances of the /forceremoval operation by event ID 29234. In Windows Server 2003 the System event log identifies forcibly demoted DCs by event ID 29239.

1. Click Start, click Run, and then type the following command:
   
   dcpromo /forceremoval
   
   
   Click Ok.
    
2. At the Welcome to the Active Directory Installation Wizard page, click Next.
   
    
3. At the Force the Removal of Active Directory page, click Next.
   
    
4. In Administrator Password, type the password and confirmed password that you want to assign to the Administrator account of the local SAM database, and then click Next.
   
    
5. In Summary, click Next.
   
    
6. Watch as the process runs. Do not disturb it. Go drink some coffee. It should take no longer than a few minutes.
   
    
7. When Dcpromo finishes it will prompt you to click Finish.
   
    
8. Restart the server.
   
    

After you use the dcpromo /forceremoval command, all the remaining metadata for the demoted DC is not deleted on the surviving domain controllers, and therefore you must manually remove it by using the NTDSUTIL command. For more information please read my “Delete Failed DCs from Active Directory” article (insert link).

Links

Domain controllers do not demote gracefully when you use the Active Directory Installation Wizard to force demotion in Windows Server 2003 and in Windows 2000 Server - 332199


Using Ntdsutil.exe to transfer or seize FSMO roles to a domain controller - 255504

Permissions Are Affected After You Demote a Domain Controller - 320230

What is the Recovery Storage Group?

The Recovery Storage Group (RSG) is a new type of storage group in Exchange 2003 that essentially allows you to mount a copy of a mailbox store onto a production Exchange 2003 server. You can then recover data within the restored mailbox store whilst the current store is still running. Use of the RSG on a production server won't interfere with the users as the RSG is logically isolated; users cannot log into it, and mail cannot be delivered to it. As you can probably guess, the main benefit here is that you don't necessarily need a spare disaster recovery server in its own Active Directory forest to recover a single mailbox or single mailbox store, as was required in Exchange 2000.

Also, one other benefit of the RSG is something that is referred to as a "dial tone recovery strategy". The idea here is to create a brand new blank database in the event of problems with the production database. This way, your users are up and running much quicker and can send and receive new messages straight away. The failed production database can then be restored to the RSG, the old data extracted using ExMerge, and then transferred back into the users' mailboxes. Of course, once the production database is available again, it makes sense to put the temporary dial tone database into the RSG and recover the data from this database, since it will be much smaller than the restored production database.

Creating the RSG

This is basically the same as creating a new storage group. One thing to note is that you can still create a RSG even if you currently have the maximum number of 4 storage groups already created. Within Exchange System Manager, navigate to your target server object. Then, right-click the server on which you wish to install the RSG and choose New / Recovery Storage Group. You will then be presented with the following screen:

Give the RSG a suitable name and also enter suitable transaction log and system path locations. Obviously, you will want to ensure that you enter different locations than those of the transaction logs belonging to the original storage group. One useful piece of information here is that, although you don't really need that much disk space for the location of the transaction log and system path locations, the paths specified here become the default location for the restored mailbox store files as well. I'll show you how to make sure you remember to modify the location of where you're going to restore your mailbox store files to a little later on. Click OK, and the RSG will now be created.

Also note that if you now bring up the properties of the newly created RSG, you will notice that the log file prefix field has been filled in with R00; this becomes the prefix used for the transaction logs within the RSG in the same way that the default first storage group uses a prefix of E00 for its transaction logs.

Adding a Mailbox Store

Now we need to add the desired mailbox store to the RSG. To do this, just right-click the RSG in ESM and choose Add Database to Recover. The following screen will be presented:

You'll see from this screen shot that you can add Exchange 2003 and Exchange 2000 SP3 mailbox stores to the RSG. However, note that these stores must be from servers within the same Administrative Group. Nonetheless, the ability to add an Exchange 2000 SP3 mailbox store is a really useful feature. Be warned, though, that once you add an Exchange 2000 SP3 mailbox store to a RSG, the mailbox store is upgraded to the same version as mailbox stores running on the server with the RSG. Therefore, you will not be able to copy this mailbox store back to its original server without upgrading that server to the same Exchange version as was in use on the server with the RSG. The method to extract data is then via ExMerge, which I'll cover later on. Also, you'll see that only mailbox stores are presented as possibilities to add to the RSG - public folder stores cannot be created in the RSG.

Once you've selected your chosen store, just click OK. The properties of that mailbox store are then presented as shown below. If you click the Database tab, you'll notice that the default location for where the store files will be recovered to is the same as that of the RSG you previously created. As I said earlier, this may be a problem, since it is likely that if you accepted the defaults during the creation of the RSG, your chosen location may not have enough disk space to hold the entire restored mailbox store. Now is the time to change the locations if disk space is an issue.

Other important things to note are that, by default, the newly added database should be dismounted. Also, if you bring up the properties of this database in the RSG and click the Database tab, you should notice that the Do not mount this store at start-up check box is automatically checked and is also greyed out. This is a feature of the RSG. Databases cannot be set to automatically mount; they must be mounted manually by the administrator. Also, the This database can be overwritten by a restore check box should be selected.

Restoring The Mailbox Store

This process should be the same as per any normal mailbox store restore process really. I'm not going to go into massive detail here, as restoring a mailbox store can potentially be a large subject, and this article is already large enough! In my example here, I'm going to be using the Windows Backup utility. As you can see, I've elected to restore the logs and mailbox store from my backup. The good thing about performing these online restores is that the RSG should automatically be detected by the backup utility. I also chose to have a hard recovery performed by selecting the Last Backup Set option in the Windows Backup utility.

Once the database has been restored, it will be mounted if you select the option to mount it after the restoration process. I chose not to, and mounted it manually. However, the result is the same. Here's the restored and mounted database. Admittedly, this one doesn't contain much information!

Extracting The Data

The ExMerge utility is used to extract data from the RSG mailbox store. Note though, that the only supported interface for extracting this data is via the Exchange 2003 version of ExMerge. You can find this version of ExMerge at the Exchange 2003 site here. I won't make this article any longer than it needs to be by posting lots of screen dumps of each ExMerge screen that you encounter as you proceed with the utility. The main screen that's of interest here is the Database Selection screen, since it is important that you choose the Recovery Storage Group. After doing this, you will be presented with a list of mailboxes held in the mailbox store in the RSG which you can then export to PST. It's that easy.

The RSG is an excellent utility for recovering single mailboxes or mailbox stores. It isn't a replacement for sound disaster recovery processes though.

When you try to remove a domain controller from your Active Directory domain by using Dcpromo.exe and fail, or when you began to promote a member server to be a Domain Controller and failed (the reasons for your failure are not important for the scope of this article), you will be left with remains of the DCs object in the Active Directory. As part of a successful demotion process, the Dcpromo wizard removes the configuration data for the domain controller from Active Directory, but as noted above, a failed Dcpromo attempt might leave these objects in place.

The effects of leaving such remains inside the Active Directory may vary, but one thing is sure: Whenever you'll try to re-install the server with the same computername and try to promote it to become a Domain Controller, you will fail because the Dcpromo process will still find the old object and therefore will refuse to re-create the objects for the new-old server.

In the event that the NTDS Settings object is not removed correctly you can use the Ntdsutil.exe utility to manually remove the NTDS Settings object.

If you give the new domain controller the same name as the failed computer, then you need perform only the first procedure to clean up metadata, which removes the NTDS Settings object of the failed domain controller. If you will give the new domain controller a different name, then you need to perform all three procedures: clean up metadata, remove the failed server object from the site, and remove the computer object from the domain controllers container.

You will need the following tool: Ntdsutil.exe, Active Directory Sites and Services, Active Directory Users and Computers.

Also, make sure that you use an account that is a member of the Enterprise Admins universal group.

Caution: Using the Ntdsutil utility incorrectly may result in partial or complete loss of Active Directory functionality.

To clean up metadata

1. At the command line, type Ntdsutil and press ENTER.

C:WINDOWS>ntdsutil ntdsutil:

2. At the Ntdsutil: prompt, type metadata cleanup and press Enter.

ntdsutil: metadata cleanup metadata cleanup:

3. At the metadata cleanup: prompt, type connections and press Enter.

metadata cleanup: connections server connections:

4. At the server connections: prompt, type connect to server <servername>, where <servername> is the domain controller (any functional domain controller in the same domain) from which you plan to clean up the metadata of the failed domain controller. Press Enter.

server connections: connect to server server100 Binding to server100 ... Connected to server100 using credentials of locally logged on user. server connections:

Note: Windows Server 2003 Service Pack 1 eliminates the need for the above step.

5. Type quit and press Enter to return you to the metadata cleanup: prompt.

server connections: q metadata cleanup:

6. Type select operation target and press Enter.

metadata cleanup: Select operation target select operation target:

7. Type list domains and press Enter. This lists all domains in the forest with a number associated with each.

select operation target: list domains Found 1 domain(s) 0 - DC=caloni,DC=net select operation target:

8. Type select domain <number>, where <number> is the number corresponding to the domain in which the failed server was located. Press Enter.

select operation target: Select domain 0 No current site Domain - DC=caloni,DC=net No current server No current Naming Context select operation target:

9. Type list sites and press Enter.

select operation target: List sites Found 1 site(s) 0 - CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=caloni,DC=net select operation target:

10. Type select site <number>, where <number> refers to the number of the site in which the domain controller was a member. Press Enter.

select operation target: Select site 0 Site - CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=caloni,DC=net Domain - DC=caloni,DC=net No current server No current Naming Context select operation target:

11. Type list servers in site and press Enter. This will list all servers in that site with a corresponding number.

select operation target: List servers in site Found 2 server(s) 0 - CN=SERVER200,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=caloni,DC=net 1 - CN=SERVER100,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=caloni,DC=net select operation target:

12. Type select server <number> and press Enter, where <number> refers to the domain controller to be removed.

select operation target: Select server 0 Site - CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=caloni,DC=net Domain - DC=caloni,DC=net Server - CN=SERVER200,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=caloni,DC=net DSA object - CN=NTDS Settings,CN=SERVER200,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=caloni,DC=net DNS host name - server200.caloni.net Computer object - CN=SERVER200,OU=Domain Controllers,DC=caloni,DC=net No current Naming Context select operation target:

13. Type quit and press Enter. The Metadata cleanup menu is displayed.

select operation target: q metadata cleanup:

14. Type remove selected server and press Enter.

You will receive a warning message. Read it, and if you agree, press Yes.

metadata cleanup: Remove selected server "CN=SERVER200,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=caloni,DC=net" removed from server "server100" metadata cleanup:

At this point, Active Directory confirms that the domain controller was removed successfully. If you receive an error that the object could not be found, Active Directory might have already removed from the domain controller.

15. Type quit, and press Enter until you return to the command prompt.

To remove the failed server object from the sites

1. In Active Directory Sites and Services, expand the appropriate site.
2. Delete the server object associated with the failed domain controller.
   

To remove the failed server object from the domain controllers container

1. In Active Directory Users and Computers, expand the domain controllers container.
2. Delete the computer object associated with the failed domain controller.
   

3. Windows Server 2003 AD might display a new type of question window, asking you if you want to delete the server object without performing a DCPROMO operation (which, of course, you cannot perform, otherwise you wouldn't be reading this article, would you...) Select "This DC is permanently offline..." and click on the Delete button.
   

4. AD will display another confirmation window. If you're sure that you want to delete the failed object, click Yes.
   

To remove the failed server object from DNS

1. In the DNS snap-in, expand the zone that is related to the domain from where the server has been removed.
2. Remove the CNAME record in the _msdcs.root domain of forest zone in DNS. You should also delete the HOSTNAME and other DNS records.
   

3. If you have reverse lookup zones, also remove the server from these zones.

Other considerations

Also, consider the following:

• If the removed domain controller was a global catalog server, evaluate whether application servers that pointed to the offline global catalog server must be pointed to a live global catalog server.
• If the removed DC was a global catalog server, evaluate whether an additional global catalog must be promoted to the address site, the domain, or the forest global catalog load.
• If the removed DC was a Flexible Single Master Operation (FSMO) role holder, relocate those roles to a live DC.
• If the removed DC was a DNS server, update the DNS client configuration on all member workstations, member servers, and other DCs that might have used this DNS server for name resolution. If it is required, modify the DHCP scope to reflect the removal of the DNS server.
• If the removed DC was a DNS server, update the Forwarder settings and the Delegation settings on any other DNS servers that might have pointed to the removed DC for name resolution.

What are the FSMO Roles in Active Directory?

Windows 2000/2003 Multi-Master Model

A multi-master enabled database, such as the Active Directory, provides the flexibility of allowing changes to occur at any DC in the enterprise, but it also introduces the possibility of conflicts that can potentially lead to problems once the data is replicated to the rest of the enterprise. One way Windows 2000/2003 deals with conflicting updates is by having a conflict resolution algorithm handle discrepancies in values by resolving to the DC to which changes were written last (that is, "the last writer wins"), while discarding the changes in all other DCs. Although this resolution method may be acceptable in some cases, there are times when conflicts are just too difficult to resolve using the "last writer wins" approach. In such cases, it is best to prevent the conflict from occurring rather than to try to resolve it after the fact.

For certain types of changes, Windows 2000/2003 incorporates methods to prevent conflicting Active Directory updates from occurring.

Windows 2000/2003 Single-Master Model

To prevent conflicting updates in Windows 2000/2003, the Active Directory performs updates to certain objects in a single-master fashion.

In a single-master model, only one DC in the entire directory is allowed to process updates. This is similar to the role given to a primary domain controller (PDC) in earlier versions of Windows (such as Microsoft Windows NT 4.0), in which the PDC is responsible for processing all updates in a given domain.

In a forest, there are five FSMO roles that are assigned to one or more domain controllers. The five FSMO roles are:

Schema Master:

The schema master domain controller controls all updates and modifications to the schema. Once the Schema update is complete, it is replicated from the schema master to all other DCs in the directory. To update the schema of a forest, you must have access to the schema master. There can be only one schema master in the whole forest.

Domain naming master:

The domain naming master domain controller controls the addition or removal of domains in the forest. This DC is the only one that can add or remove a domain from the directory. It can also add or remove cross references to domains in external directories. There can be only one domain naming master in the whole forest.

Infrastructure Master:

When an object in one domain is referenced by another object in another domain, it represents the reference by the GUID, the SID (for references to security principals), and the DN of the object being referenced. The infrastructure FSMO role holder is the DC responsible for updating an object's SID and distinguished name in a cross-domain object reference. At any one time, there can be only one domain controller acting as the infrastructure master in each domain.

Note: The Infrastructure Master (IM) role should be held by a domain controller that is not a Global Catalog server (GC). If the Infrastructure Master runs on a Global Catalog server it will stop updating object information because it does not contain any references to objects that it does not hold. This is because a Global Catalog server holds a partial replica of every object in the forest. As a result, cross-domain object references in that domain will not be updated and a warning to that effect will be logged on that DC's event log. If all the domain controllers in a domain also host the global catalog, all the domain controllers have the current data, and it is not important which domain controller holds the infrastructure master role.

Relative ID (RID) Master:

The RID master is responsible for processing RID pool requests from all domain controllers in a particular domain. When a DC creates a security principal object such as a user or group, it attaches a unique Security ID (SID) to the object. This SID consists of a domain SID (the same for all SIDs created in a domain), and a relative ID (RID) that is unique for each security principal SID created in a domain.  Each DC in a domain is allocated a pool of RIDs that it is allowed to assign to the security principals it creates. When a DC's allocated RID pool falls below a threshold, that DC issues a request for additional RIDs to the domain's RID master. The domain RID master responds to the request by retrieving RIDs from the domain's unallocated RID pool and assigns them to the pool of the requesting DC. At any one time, there can be only one domain controller acting as the RID master in the domain.

PDC Emulator:

The PDC emulator is necessary to synchronize time in an enterprise. Windows 2000/2003 includes the W32Time (Windows Time) time service that is required by the Kerberos authentication protocol. All Windows 2000/2003-based computers within an enterprise use a common time. The purpose of the time service is to ensure that the Windows Time service uses a hierarchical relationship that controls authority and does not permit loops to ensure appropriate common time usage.

The PDC emulator of a domain is authoritative for the domain. The PDC emulator at the root of the forest becomes authoritative for the enterprise, and should be configured to gather the time from an external source. All PDC FSMO role holders follow the hierarchy of domains in the selection of their in-bound time partner.

In a Windows 2000/2003 domain, the PDC emulator role holder retains the following functions:

• Password changes performed by other DCs in the domain are replicated preferentially to the PDC emulator.

• Authentication failures that occur at a given DC in a domain because of an incorrect password are forwarded to the PDC emulator before a bad password failure message is reported to the user.

• Account lockout is processed on the PDC emulator.

• Editing or creation of Group Policy Objects (GPO) is always done from the GPO copy found in the PDC Emulator's SYSVOL share, unless configured not to do so by the administrator.

• The PDC emulator performs all of the functionality that a Microsoft Windows NT 4.0 Server-based PDC or earlier PDC performs for Windows NT 4.0-based or earlier clients.

This part of the PDC emulator role becomes unnecessary when all workstations, member servers, and domain controllers that are running Windows NT 4.0 or earlier are all upgraded to Windows 2000/2003. The PDC emulator still performs the other functions as described in a Windows 2000/2003 environment.

At any one time, there can be only one domain controller acting as the PDC emulator master in each domain in the forest.

IMPORTANT: This article contains information about editing the registry.

Before you edit the registry, make sure you understand how to restore it if

a problem occurs. For information about how to do this, view the "Restoring

the Registry" Help topic in Regedit.exe or the "Restoring a Registry Key" Help

topic in Regedt32.exe.

SUMMARY

 

WARNING: Using Registry Editor incorrectly can cause serious problems that may

require you to reinstall your operating system. Microsoft cannot guarantee that

problems resulting from the incorrect use of Registry Editor can be solved. Use

Registry Editor at your own risk.

 

For information about how to edit the registry, view the "Changing Keys and

Values" Help topic in Registry Editor (Regedit.exe) or the "Add and Delete

Information in the Registry" and "Edit Registry Data" Help topics in

Regedt32.exe. Note that you should back up the registry before you edit it. If

you are running Windows NT or Windows 2000, you should also update your

Emergency Repair Disk (ERD).

 

Microsoft Windows Server provides administration utilities for Dynamic Host

Configuration Protocol (DHCP) you can use to manage DHCP servers. DHCP Manager

(Dhcpadmn.exe) is provided in Windows NT 4.0, while the DHCP Snap-in is provided

as part of the MMC in Windows 2000/2003. Neither utility permits you to move a DHCP

database from one server to another server. This article explains how to move a

database from a server to another server.

 

Note that there are two sections to this article, and each section should be

treated independently. Use only the section that corresponds to the type of

migration you want to do.

 

IMPORTANT: It is strongly recommended that you perform the migration by using

Regedt32 as detailed in the following article in the Microsoft Knowledge Base:

 

   Q130642 How to Move a DHCP Database to Another Windows Server

 

WARNING: This document is provided only for use where a migration using the steps

in the preceding article is not possible and scripting is the only way of

performing the migration.

 

 

IMPORTANT: Moving a DHCP Database incorrectly can leave your computer in an

unstable state. Because of this, it is strongly recommended that before you try

to perform a database migration you should:

 

 - Create a backup of your working configuration.

 

 - Test these procedures in a lab environment.

 

 - Perform all of the following steps exactly.

 

Also, it is assumed the destination server does not have the DHCP Server service

installed. If the DHCP Server service has been installed it must be removed. To

do so:

 

1. Click Start, point to Settings, click Control Panel, and then double-click

   Add/Remove Programs.

 

2. Click Add/Remove Windows Components, double-click Networking Services (the

   words, not the check box), and then click to clear the DHCP Server check box.

 

After you have installed the DHCP Server service on the destination server, it is

important that you do not start the DHCP MMC until you are instructed to do so.

The first time you start the MMC, it checks for and creates certain settings

that should only be created at the end of the procedures listed below.

 

NOTE: It is possible that on the source server the DHCP database name and

location have been changed from the default of

%systemroot%system32dhcpdhcp.mdb. This migration procedure is not affected by

differences in database location between source and destination servers, and

will require the destination DHCP server to use the default name and path

settings of %systemroot%system32dhcpdhcp.mdb.

 

Also, several of the following steps state that commands such as "net stop

dhcpserver" (without the quotation marks) should be run. You should run these

commands at a command prompt.

 

From the Source DHCP Server:

 

1. Dump the configuration of the Windows based DHCP server:

   dump the configuration from a Windows Server  based computer. Also, the Windows

   NT 4.0-based DHCP server must be running Windows NT 4.0 Service Pack 2 or

   higher. On any Windows 2000-based server running DHCP, type "netsh dhcp

   server <IP address> dump > c:export.txt" (without the quotation

   marks) at a command prompt, and then press ENTER, where <IP address> is

   the IP address of the Windows NT 4.0-based DHCP server.

 

2. To prevent DHCP from starting after the database has been transferred,

   disable the DHCP Server service by using the Services tool in Control Panel:

 

   a. Click Start, point to Settings, click Control Panel, and then double-click

      Services.

 

   b. In the Services box, click Microsoft DHCP Server, click Startup, and then

      click Disabled under Startup Type.

 

3. Stop the DHCP Server service by using the "net stop dhcpserver" (without the

   quotation marks) command at a command prompt.

 

From the Destination DHCP Server:

 

1. Install the DHCP server service:

 

   a. Click Start, point to Settings, click Control Panel, and then double-click

      Add/Remove Programs.

 

   b. Click Add/Remove Windows Components, double-click Networking Services (the

      words, not the check box), and then click to select the Dynamic Host

      Configuration Protocol (DHCP) check box.

 

2. Remove the Option definitions from the destination DHCP server by using

   Registry Editor to delete the following registry key:

 

   HKEY_LOCAL_MACHINESOFTWAREMicrosoftDhcpServerConfigurationOptionInfo

 

3. Copy the Export.txt file to the destination server, and then rename the file

   to C:Import.txt.

 

4. Edit the Import.txt file with Notepad.exe and replace the IP address of the

   source DHCP server with the IP address of the destination DHCP server.

   Perform a Replace on the string "SERVER <x.x.x.x>" with "SERVER

   <y.y.y.y>", where <x.x.x.x> is the source DHCP server address and

   <y.y.y.y> is the destination DHCP server address.

 

   IMPORTANT: Do not just string replace the "x.x.x.x" with "y.y.y.y" as either

   address may be used in option values within a scope. Save your changes.

 

5. If the DHCP database name or path on the source server is different than the

   database name or path on the destination server, you must edit the Import.txt

   file and correct the values for any or all of the following settings:

   AuditLog, DatabaseBackupPath, DatabaseName, and DatabasePath. Note that the

   default path is typically c:winntsystem32dhcpDhcp.mdb. Save your changes.

 

6. Load the Import.txt file into the destination DHCP server with the "netsh

   exec c:import.txt" (without the quotation marks) command.

 

7. Stop the DHCP Server service on the destination server with the "net stop

   dhcpserver" (without the quotation marks) command.

 

8. Delete all of the contents of the %systemroot%system32dhcp folder,

   including its subfolders.

 

9. Copy the DHCP database file (Dhcp.mdb) in the %systemroot%system32dhcp

   folder on the source server to the %systemroot%system32dhcp folder on the

   destination server.

 

10. Start the DHCP Server service with the "net start dhcpserver" (without the

   quotation marks) command.

 

   IMPORTANT: You should receive the following error message:

 

   System error 20036 has occurred. The system cannot find message text for

   message number 0x4e44 in the message file for BASE.

 

   Receiving this error message is normal, please proceed to the next step.

 

11. If you also receive the following error message, copy the Edb500.dl_ file

   from the Windows 2000 CD-ROM, expand it to the System32 folder, repeat step

   8, and when you no longer receive this error message, continue to the next

   step.

 

      NOTE: This also corresponds with an EventID 1008 in the Application log.

 

12. View the Application Log in the Event Viewer. If the JetConv application

   logs EventID 1000, the database has been converted successfully.

 

13. Start the DHCP Server snap-in from the Administrative Tools group.

 

14. Click the destination DHCP server, and then click Reconcile All Scopes on

   the Action menu. Click Verify. If any leases need to be reconciled, click

   Reconcile to synchronize the registry and database.

 

15. If the Windows 2000-based server is part of an Active Directory domain, the

   server must be Authorized.

 

To move a DHCP database from a Windows 2000/2003 Server to a Windows 2000/2003 Server:

 

IMPORTANT: Moving a DHCP Database incorrectly can leave your computer in an

unstable state. Because of this, it is strongly recommended that before you try

to perform a database migration you should:

 

 - Create a backup of your working configuration.

 

 - Test these procedures in a lab environment.

 

 - Perform all of the following steps exactly.

 

Also, it is assumed the destination server does not have the DHCP Server service

installed. If the DHCP Server service has been installed it must be removed

first. To do so:

 

1. Click Start, point to Settings, click Control Panel, and then double-click

   Add/Remove Programs.

 

2. Click Add/Remove Windows Components, double-click Networking Services (the

   words, not the check box), and then click to clear the DHCP Server check box.

 

After you have installed the DHCP Server service on the destination server, it is

important that you do not start the DHCP MMC until you are instructed to do so.

The first time you start the MMC, it checks for and creates certain settings

that should only be created at the end of the procedures listed below.

 

NOTE: It is possible that on the source server the DHCP database name and

location have been changed from the default of

%systemroot%system32dhcpdhcp.mdb. This migration procedure is not affected by

differences in database location between source and destination servers, and

will require the destination DHCP server to use the default name and path

settings of %systemroot%system32dhcpdhcp.mdb.

 

Also, several of the following steps state that commands such as "net stop

dhcpserver" (without the quotation marks) should be run. You should run these

commands at a command prompt.

 

From the Source DHCP Server:

 

1. Dump the configuration of the source DHCP server by using the "netsh dhcp

   server <x.x.x.x> dump >c:export.txt" (without the quotation marks)

   command from any Windows 2000-based DHCP Server, where <x.x.x.x> is the

   IP address of the source DHCP server.

 

2. To prevent DHCP from starting after the database has been transferred,

   disable the DHCP Server service:

 

   a. Click Start, point to Programs, point to Administrative Tools, and then

      click Computer Management.

 

   b. Double-click "Services and Applications", click Services, right-click the

      DHCP server on the Services list, and then click Properties.

 

   c. Change the "Startup type" to Disabled, and then click OK.

 

3. Stop the DHCP Server service by using the "net stop dhcpserver" (without the

   quotation marks) command at a command prompt.

 

From the Destination DHCP Server:

 

1. Install the DHCP Server service:

 

   a. Click Start, point to Settings, click Control Panel, and then double-click

      Add/Remove Programs.

 

   b. Click Add/Remove Windows Components, double-click Networking Services (the

      words, not the check box), and then click to select the Dynamic Host

      Configuration Protocol (DHCP) check box.

 

2. Clear the Option definitions off of the destination DHCP server by deleting

   the following registry key:

 

   HKEY_LOCAL_MACHINESOFTWAREMicrosoftDhcpServerConfigurationOptionInfo

 

3. Copy the Export.txt file to the destination server, and then rename the file

   to c:Import.txt.

 

4. Edit the Import.txt file with Notepad.exe and replace the IP address of the

   source DHCP server with the IP address of the destination DHCP server.

   Perform a Replace on the string "SERVER <x.x.x.x>" with "SERVER

   <y.y.y.y>", where <x.x.x.x> is the source DHCP server address and

   <y.y.y.y> is the destination DHCP server address.

 

   IMPORTANT: Do not just string replace the "x.x.x.x" with "y.y.y.y" as either

   address may be used in option values within a scope. Save your changes.

 

5. If the DHCP database name or path on the Source server is different than the

   database name or path on the destination server, you must edit the Import.txt

   file to correct the values for any or all of the following settings:

   AuditLog, DatabaseBackupPath, DatabaseName, and DatabasePath. Note that the

   default path is typically c:winntsystem32dhcpDhcp.mdb. Save your changes.

 

6. Load the Import.txt file into the destination DHCP server by using the "netsh

   exec c:Import.txt" (without the quotation marks) command.

 

7. Stop the DHCP Server service by using the "net stop dhcpserver" (without the

   quotation marks) command.

 

8. Delete all of the contents of the %systemroot%system32dhcp folder,

   including subfolders.

 

9. Copy the DHCP database file (Dhcp.mdb) in the %systemroot%system32dhcp

   folder on the source server to the %systemroot%system32dhcp folder on the

   destination server.

 

10. Start the DHCP Server service with the "net start dhcpserver" (without the

   quotation marks) command.

 

11. Start the DHCP Server snap-in from the Administrative Tools group. Click the

   destination DHCP server, and then click Reconcile All Scopes on the Action

   menu. Click Verify. If any leases need to be reconciled, click Reconcile to

   synchronize the registry and database.

 

12. If the Windows 2000-based server is part of an Active Directory domain, the

   server must be Authorized.

Following the options will be described for allowing a user, on purpose delegated, to effect, for the standard users of the OU in foreign site, the options related to the reset password, unlock account and to able the flag that allows change password at following logon are:

 

• allow Reset Password permission for user objects—grants permission to reset an account’s password
• allow Write lockoutTime permission for user objects—grants permission to unlock an account
• allow Write pwdLastSet permission for user objects—grants permission to set User must change password at next logon account property
• allow Read AccountRestrictions permission for user objects—grants permission to read all account options

 

 

 

NB: this delegation permit, at user delegated, only reset password and unlock for only standard users, therefore  this user is not able to reset this option for Advanced users like Administrators or similar.

 

 

Step1: Right klick OU (third level) standardUsers and select Delegation Wizard

 

Step2: select user for the delegation

 

Step3:

 Step4:

 

Step5:

 

Step6: OU Proprieties  that contain standardUsers, and select user delegated in security tab

Below the options that must be selected manually:

 

Step7:

Clik Advanced tab of the user, clear inherit flag (Allow inehritable permissione/copy) and display detail of permission, after this select these option: “Write pwdLastSet” e “Read pwdLastSet” clickok, ok and close window

Add option “Read lokout time” and  “write lokout time” how display below (this option permit unlock of the user):

 

My friend and colleague Manlio Frizzi, have a depth approach toward the 

Virtualization Techniques with VMware, his blog it is a good reference for

problem and analyzing about this product.

Please visit his Blog  for great details... and many thanks to Manlio  for the precious shared information with the ICT community

http://virtualaleph.blogspot.com