Step-By-Step: Migration of DHCP from Windows Server 2003 to Windows Server 2012

Migration from Windows Server 2003 to 2012 has been deemed troublesome by few as the netsh DHCP command-line was replaced in Windows Server 2012 by PowerShell. The process however is actually quite easy and can be completed in a few steps.

Prerequisite

Download Windows Server 2012. If you plan on completing this Step-By-Step in a virtual lab, it is recommended to download the FREE Hyper-V Server 2012 first.

Beginning the export process on Windows Server 2003

1. On the Windows 2003 DHCP server, navigate to a command prompt
2. Type the following Command: netsh
3. Type the following Command: DHCP
4. Type the following Command: server \\Name or IP Address
5. Type the following Command: export c:\w2k3DHCPdb all
   
   Note You must have local administrator permissions to export the data.

Importing the DHCP database on Windows Server 2012

1. Copy the exported DHCP database file to the local hard disk of the Windows Server 2008-based computer. 
2. From within Server Manager, select Add roles and features
   
   
3. Select Role-based of featured-based installation and select Next.
   
4. On the Server Selection window, leave the default and select Next. When the Server Roles window opens, select DHCP. Select Add Features in the pop-up window, then select Next.
   
   
5. Once the DHCP install has been completed, select DHCP located in the Server Manager dashboard
6. Right click the designated DHCP server in the services pane, then select Stop.
7. Delete the DHCP.mdb file under c:\windows\system32\DHCP folder.
8. Return to DHCP located in the Server Manager dashboard
9. Right click the designated DHCP server in the services pane, then select Start.
10. Right-click on the bottom left hand side of the desktop screen to invoke the admin menu
    
    
11. Select Command Prompt (Admin) to open the cmd prompt using elevated privileges. 
12. Type the following Command: netsh
13. Type the following Command: DHCP
14. Type the following Command: server \\Name or IP Address
15. Type the following Command: import c:\w2k3DHCPdb
16. Close the command prompt when completed.
17. Return to DHCP located in the Server Manager dashboard.
18. Right click the designated DHCP server in the services pane, then select Restart.
19. Disable and remove DHCP from the Windows 2003 server.

Simply setup your scope options for your new Windows Server 2012 DHCP server and then Authorize it within your domain and the  migration is complete.

Step-By-Step: Active Directory Migration from Windows Server 2003 to Windows Server 2012 R2

With the end of support for Windows XP, Office 2003 and Exchange 2003 now upon us, April 8th 2014 to be exact, attention now turns to Windows Server or specifically Windows Server 2003.  End of support for Windows Server 2003 is currently slated for July 14th 2015 and a great many organizations still utilize said offering as the cornerstone to their infrastructure to this day.  One question to keep in mind though is that with the move on the client end to Windows 8.1, will Windows Server 2003 or 2003 R2 be robust enough to properly enable employees and provide secure access to the plethora of devices in a world now dominated by BYOD?  Alternatively an IT administrator might ponder on the further enablement invoked via the deployment of Windows Server 2012 R2 should it be deployed in said organization.  Lets explore this possibility via the cornerstone of access enablement offered via Windows Server by investigating the evolution of the Active Directory offering now found in Windows Server 2012 R2

As you may know, Active Directory provides authentication and authorization mechanisms as well as framework from within other related services that can be deployed. As an LDAP compliant database, it commonly contains the most used objects such as users, computers, and groups organized into organizational units or OUs by any number of logical or business needs. Group Policy Objects or GPOs are then linked to OUs to centralize the settings for various users or computers across an organization. Part of the quandaries that IT professionals face is taking advantage of nuances provided in Active Directory in newer server offerings such as Windows Server 2012.  As detailed in Pierre's post, "Windows Server 2012 Active Directory – What’s New?", Active Directory provided in Windows Server 2012 R2 is provided impactful enhancements.  Yet some organizations choose not to migrate due to reasons of uncertainty.

This Step-By-Step has been created to assist with that uncertainty and provide guidance for IT professionals looking to migrate their organizations Active Directory offering from Windows Server 2003 to 2012 R2.

Prerequisites

1. Download Windows Server 2012 R2 and create your lab environment. (Instructions can be found here)
2. Complete Step-By-Step: Adding a Windows Server 2012 R2 Domain Controller to an Existing Windows Server 2003 network

Transferring the Flexible Single Master Operations (FSMO) Role

1. Open the Active Directory Users and Computers console on your new Windows Server 2012 R2 computer.
2. Right click your domain and select Operations Masters in the sub menu.
3. In the Operations Masters window, ensure the RID tab is selected.
4. Select the Change button.
   
   
5. Select Yes when asked about transferring the operations master role.
6. Once the operations master role has successfully transferred, click OK to continue.
7. Ensure the Operations Master box now shows your new 2012 R2 Windows Server.
8. Repeat steps 4 to 6 for the PDC and Infrastructure tabs.
9. Once completed, click Close to close the Operations Masters window.
10. Close the Active Directory Users and Computers window.

Changing the Active Directory Domain Controller 

1. Open the Active Directory Domains and Trusts console on your new Windows Server 2012 R2 computer.
2. Right click your domain and select Change Active Directory Domain Controller... in the sub menu.
3. In the Change Directory Server window, select This Domain Controller or AD LDS instance.
4. Select your new 2012 R2 Windows Server.
   
   
5. Click OK to continue.
6. Back in the Active Directory Domains and Trusts window, hover over the Active Directory Domains and Trusts found in the folder tree on the left hand side to ensure the server now reflects your new 2012 R2 Windows server.
7. Right click Active Directory Domains and Trusts found in the folder tree and select Operations Manager... in the sub menu.
8. In the Operations Master window, click Change to transfer the domain naming master role to the 2012 R2 Windows Server.
9. When asked if you are sure you wish to transfer the operations master role to a different computer, clickYes.
10. Once the operations master is successfully transferred, click OK to continue.
11. Click Close to close the Operations Master window.
12. Close the Active Directory Domains and Trusts console.

Changing the Schema Master

1. Open a command prompt in administration view on your new Windows Server 2012 R2 computer.
2. On the command prompt window, enter regsvr32 schmmgmt.dll and hit enter.
3. Once completed successfully, click OK to close the RegSvr32 window.
   
   
4. Close the command prompt.

Add the Active Directory Schema Console from MMC

1. Open a MMC console on your new Windows Server 2012 R2 computer.
2. Click File > Add/Remove Snap-in...
3. In the Add or Remove Snap-ins window, select Active Directory Schema and click the Add >button.
   
   
4. Click OK to continue.

Change the Schema Master

1. In the same MMC console, right click Active Directory Schema and select Change Active Directory Domain Controller... in the sub menu.
2. In the Change Directory Server window, select This Domain Controller or AD LDS instance.
3. Select your new 2012 R2 Windows Server.
4. Click OK to continue.
5. A warning will appear stating that the Active Directory Schema snap-in in not connected. Click OK to continue.
6. Hover over the Active Directory Schema folder in the folder tree to ensure the new Windows Server 2012 R2 computer is shown. 
7. Now right click Active Directory Schema and select Operations Master... in the sub menu.
8. In the Change Schema Master window, click Change to transfer the schema master role to the 2012 R2 Windows Server. 
9. When asked if you are sure you wish to transfer the schema master role to a different computer, click Yes.
10. Once the schema master is successfully transferred, click OK to continue.
11. Click Close to close the Change Schema Master window.
12. In the MMC, click File > Exit.
13. When asked to save the console, click No.

 Once completed, open the Active Directory Users and Computers console to verify that the Active Directory database successfully replicated to your new Windows Server 2012 R2 computer.  Be aware that the database replication may take some time depending on the number of objects in Active Directory.

Removing the 2003 Windows Server from the Global Catalog Server

1. Open Active Directory Sites and Services on your new Windows Server 2012 R2 computer.
2. Expand the Sites folder, then the Default-First-Site-Name folder, then the Servers folder.
3. Expand both listed servers. One should be your new 2012 Windows Server and one should be you 2003 Windows Server.
4. Right click NTDS Settings found under your old 2003 Windows Server.
5. In the sub menu, select Properties.
6. Under the General Tab, unselect Global Catalog and then click the Apply button.
7. Click OK to continue.
8. Close the Active Directory Sites and Services window.
9. Verify that your new 2012 R2 Windows Server is running the FSMO role by opening the command prompt in Administrative view and running the following command: Netdom query fsmo.
10. In the Network and Sharing Center, be sure to change the Preferred DNS server to match the Alternate DNS server, then delete the IP address listed under the Alternate DNS server should it currently be pointed to the old 2003 Windows Server.

All that's left is to demote the old 2003 Windows server by first adding the new 2012 R2 Windows Server as the Primary DNS, followed by running DCPROMO to demote the old 2003 Windows server. Be sure to also visit Microsoft Virtual Academy created to further enable IT professionals in regards task such as migrating to Windows Server 2012 R2.

To upgrade from the evaluation version of Operations Manager to a licensed version

To upgrade from the evaluation version of Operations Manager to a licensed version

1. On a management server, click Start, click All Programs, click Microsoft System Center 2012, click Operations Manager, and then click Operations Manager Command Shell.
2. In the Operations Manager Command Shell, type the following command:

   Set-SCOMLicense <license_key>
3. Restart the System Center Data Access Service. You can use the Microsoft Management Console to restart services.
4. Restart the System Center Data Access Service on all management servers in the management group.

For more information about Set-SCOMLicense, type the following in the Operations Manager Command Shell:

get-help Set-SCOMLicense

For current information about your license, you can use the Get-SCOMLicense cmdlet. For more information, type the following in the Operations Manager Command Shell:

get-help Get-SCOMLicense

Thanks,

Sam

3107348498

10 Reasons to use a Gateway Server

This is one of my favorite features/roles in OpsMgr 2007. When I refer to the Gateway Server I am referring to role in OpsMgr which can be used to monitor un-trusted domains/DMZs and not the spotted cow company that builds servers. If you are not leveraging the Gateway Server role then here are my 10 reasons why you should.

1)    In our performance tests we have noticed that the data sent from a gateway server to a management server is compressed by almost 50 percent. So if a company that has a couple of hundred agents on a remote site with low network bandwidth it is best practice to install a gateway on the remote site have all the agents report to that gateway server.

2)    The supported number of agents reporting to a gateway server has increased from 200 in RTM to 800 in Service Pack 1.

3)    In MOM 2005 if you had un-trusted domains and you did not want to turn mutual authentication off then you had to install a new management group in the un-trusted domain. With the gateway server and using certificates you can monitor agents in un-trusted domains and DMZs.

4)    If there is a firewall between the servers you only need to open one port (5723) for communication between the gateway server and management server. Instead of having all the agents communicating to the management server you can have just a single channel of communication across over network.

5)    Gateway Servers are good virtualization candidates because they have a small foot print compared to a management server. For the Gateway Server I/O write activity is usually high since queue data is persisted to disk, so users need to plan for this. 

6)    You can setup multiple gateway servers and configure them as failover servers for agents. So customers have a good HA /DR solution.

7)    Gateway Servers can use Certificate Authority or any 3^rd party certificates as far as they follow the PKCS format.

8)    Gateway servers can report to a clustered Root Management Server. The key for using with the clustered RMS is to create the cert using the cluster's virtual server name. But note if you have a gateway reporting to an RMS then should not have other agents reporting to the RMS because in a scenario where there may be on outage when the systems come back online the RMS or MS will poll from the gateway the same way as it would an agent without recognizing that the gateway has more data backed up in its queue than an agent.

9)    A Management Server license is required for each instance of the gateway server role. I know this is not really a reason but I thought I would call it out.

10) The Audit Collector can be installed on a Gateway Server but it will still need to report directly to the Audit Database.

Marc a Dev lead on our team had sent an email with the technical details for the first reason to use a Gateway Server. Below is the explanation of why we scale better in SP1 and are able to compress data a lot better as well.

The overall logical amount of data sent across the WAN is very similar between using a gateway or having the agents directly report to the collection management servers.  When using a gateway it handles heartbeat processing so we don't need to send those across the WAN but that should be a small amount of the overall traffic.  The big difference appears to be in increased compression efficiency by having all the data being routed through one node.  Compression algorithms do not have very good compression rates when very small blocks of data are compressed.  In one test (this was over some static xml text and isn't likely to be reflective of actual compression rates in the channel) on compression efficiency when using 128 byte blocks we saw a 38% reduction in size while when using 4096 bytes blocks over the same data we saw a 81% reduction in size.  When not using a gateway each agent is compressing its own small amount of data it is sending up.  When using a gateway all the data is routed through one node so we have much bigger blocks of data we are compressing at once.  Since the bandwidth savings are due to increased compression efficiencies the amount of savings will go up with the number of agents.  For a small number of agents I would expect to see a very minimal reduction in bandwidth utilization.  Our numbers were based on a test pass having hundreds of agents behind a gateway.

We weren't expecting the difference in compression rates to be this large which is where the original guidance in the perf and scale document comes from.  During one of our scale tests late in SP1 we took a look at the relative network usage and were pleasantly surprised to see the reduction in bandwidth utilization.  The bandwidth reduction should be the same between SP1 and RTM.  However in RTM you could only run 200 agents behind a gateway which would limit the savings.