Tag Archives: Windows Server 2012

Windows Server 2003 Migration: Tasks Part 4 – Implementation

Posted on by

We documented our inventory, created a plan, allocated the resources, procured the budget, and practiced our migration in a development environment. Now we are at the point where we need to implement our design in production. On the Active Directory side, this is a migration that should require minimal to no downtime. On the application side, downtime needed is determined by the application being migrated. Even if you believe there will be no downtime, it is preferable to schedule a maintenance window for the cutover and do the prep work beforehand. If we wait until a scheduled maintenance window, users know that access to systems is limited. The maintenance window gives you time to work without the pressure of connected users being inconvenienced. As we all know, even with scheduled downtime, you will always have that user who will be upset because you had a system down between the non-working hours of 2 to 5 a.m. on the Sunday morning of a holiday weekend. Even though your company has absolutely no weekend business hours. Ever. To be fair though, don’t make your scheduled maintenance window for your tax firm the morning of April 15.

As stated, the Active Directory side can be done with minimal to no down-time. We can build the required servers and have them ready for integration. We may want to wait until the maintenance window to promote the new domain controllers. We will have less chance of issues and faster initial replication when there is minimal network traffic. You may even want to isolate your servers from the rest of the network (if possible). One idea is to keep servers on separate switches from the rest of the network. If you need to isolate the servers, just pull the plug on the connection to the other switches.

How we integrate the new servers will determine the amount of changes that need to populate to the client side. Do not cut corners for the sake of expedience. For instance, giving a new DNS server the IP address of the existing DNS server it is replacing would keep you from having to change the populated DNS server address on the clients. For a very small environment, this may work fine. However, for a larger environment, it may not turn out to be as seamless as we think. Instead, we should consider a short period of coexistence as we move towards the new servers. Changes to settings on the clients can then be performed in groups of clients at a time. This will give us the opportunity to fix issues without everyone being affected. Almost all new settings on the client side can be populated utilizing DHCP and GPOs. If we utilize GPOs, we can delegate who gets the changes and when. Also, there are some steps in the migration process that we may want to set and then wait before doing more. Here are the general steps in performing an AD migration from Server 2003 to Server 2012:

  1. Make sure your current domain does not have any existing issues. This can be accomplished by running DCDIAG. Resolve any issues that the DCDIAG reports. This is usually the time that someone discovers an existing replication issue they did not know about.
  2. Make sure the domain functional level is Windows 2003. If not, change it. We are, of course assuming that you do not have any Windows 2000 Domain Controllers. That would require more planning and steps for this project. There is a confusion about domain functional level. This refers to the level of your domain controllers only. It does not matter is you have member servers of a previous generation. For instance, you can have a domain functional level of 2008 and still have Windows 2003 servers in it. The 03 servers are just not domain controllers.
  3. Know which servers have the FSMO roles. (On a domain controller, open a command prompt and run ‘netdom query fsmo’.)
  4. Prepare the domain if needed. If you are migrating to Windows 2008 R2, you will need to run ADPREP. If you are migrating to Windows Server 2012 R2, you do not have to run ADPREP. It is included in the process when adding the Active Directory Domain Services (AD DS) role to the 2012 server.
  5. Install your 2012 R2 server and add it to the domain.
  6. Add the AD DS role to your 2012 R2 server. Follow the steps in the wizard.
  7. Transfer your FSMO roles.
  8. Configure services like DHCP for the new servers.
    1. Update settings on the client side.
    2. Run for an initial coexistence period.
  9. Remove your Windows 2003 domain controllers by demoting them.
  10. Raise the domain functional level. 

This procedure is for the migration of Active Directory. It does not take into account the migration of applications hosted on Windows Server 2003. Those tasks are a separate part of the plan, but you should now be ready to move forward on those tasks.

At this point, this series of posts has given you the basic steps needed to perform a migration from Windows Server 2003 to Windows Server 2012 R2. This series was meant to give you an overview of the process and help you find the information you need. I cannot stress enough, how important it is for you to plan this out properly and test. If done right, a migration from 2003 AD is not difficult and usually goes very smoothly. If you run into issues, you are affecting your Active Directory configuration. Recovering AD can be a difficult task. In some cases, it’s so difficult, it was easier to just rebuild the domain from scratch. If you do not have the in-house expertise or are uncomfortable with aspects of this project, you can always seek help. I recommend getting help from the trained network professionals at Custom Systems.

As always, I welcome your comments or questions. Please feel free to leave them below or email me directly. Also, be sure to bookmark our site for more information from Microsoft. Also, please be sure to register for our live, Microsoft event – Windows Server 2003:  Security Risk and Remediation on February 18.

AZS-3

 

 

Craig R. Kalty (CCIA, CCEE, CCA, MCITP:EA, MCITP:SA, VCP)|
Sr. Network Consultant
craig.kalty@customsystems.com

 

 

 

©2015 Custom Systems Corporation

Upgrading Windows Server 2003 Active Directory

Posted on by

windows server 2003 R2Windows Server 2003 was like XP.  Everyone loved it and never wanted to move off of it.  And just like XP, the time is coming quickly where you will need to move away from the much loved server or become vulnerable to threats very quickly.  Once support has ended for Windows Server 2003 there will be no more security patches, but the threats will still be there.

One of the most common systems that I see on Windows Server 2003 these days is Active Directory.  That tends to be true since moving Active Directory can be a long and tedious process.  It can also cause numerous issues along the way.

Below is a basic guide on upgrading your Windows Server 2003 Active Directory to Windows Server 2012 R2.  I would not recommend doing this on your own.  This is something that takes planning and careful consideration.  Projects like this are where companies such as Custom Systems are a perfect choice.

In case you were not aware, End of Life (EOL) for support of Windows Server 2003 is currently slated for July 14, 2015.  That date is fast approaching and will be here before you know it.  Make sure to plan for these upgrades with ample time to complete them.

I will not get into what Active Directory is and what it does, as it provides authentication and authorization services as well as a framework for other related services that can be deployed.

The below guide is only a reference and should not be considered the perfect solution for all upgrades.  Each upgrade will differ and will require extensive planning. This guide assumes that you have a 2012 R2 server installed as well as have installed the Active Directory role.  Again this guide is not to be followed without proper planning and assistance.

First step is to Transfer 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.Dec 15 post 1
  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.Dec 15 post 2
  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, click yes.
  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.Dec 15 post 3
  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.Dec 15 post 4
  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 Windows Server 2012 R2 and one should be your  Windows Server 2003.
  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 (which is deprecated in Server 2012) to demote the old 2003 Windows server.

As I stated earlier, this is a basic guide to help you understand what to expect during a Windows Server upgrade. As always, please post your comments and questions below or email me directly.

 

Ryan Ash

 

Ryan Ash
Network Consultant
ryan.ash@customsystems.com

 

 
©Custom Systems Corporation 2014

 

Access Control and Authorization with Windows Server 2012

Posted on by

WindowsServer2012Sta_Web Have you ever needed to set up permissions on a network resource and the only way to satisfy the conditions for permission was to create a brand new security group?  Windows Server 2012 is the answer.

Let’s say you have a file share (network resource) that should only be accessed by people who are both managers and members of the HR group.  You have a Managers group and an HR group, but the requirements specify a mix of the two groups.  I have run across situations similar to this many times and I am betting many other domain administrators have run across this as well.

Prior to Windows 2012, we might need to create another group that contains users who satisfy both conditions.  This generates the need to administer another group.  Too many situations like this, and you have a huge list of groups to cover every condition.  The more groups you have, more the need to manually control group membership.  To get around this situation, we may manually set unique permissions directly on the network resource.  So now the administrator must update individual access directly on the resource instead of in a group membership.  Either way, we now have another individual point to administer and document.  The larger the organization, the more complicated this gets.

Best practice is to use groups for access control as opposed to using an individual account.  This makes things easier because all you need to do to give someone access permissions is to join them in a group.  However, what happens to administration when we create a group to cover many, many situations of multiple conditions?  Server 2012 has a new feature that alleviates this situation and empowers the administrator.  Dynamic Access Control is part of the advanced authorization and access control technologies.  Dynamic Access Control includes the following new functionalities:

  • Central Access Rules – the expression of authorization that includes one or more conditions.
  • Central Access Policies –used to bring together multiple rules of authorization to be applied across servers in a domain.
  • Claims – a unique identifier for user, device, and resource objects in a domain.  This identifier can be included in expressions.
  • Expressions – joins multiple conditions of authorization together to define access permissions.
  • Proposed Permissions – allows an administrator to predict the results of their conditional access expressions without actually applying the change.

Given the example above of HR Managers, we could go about setting up access permissions to the network share in a few new ways.  We could do it directly on the network share where we would create an expression that has the conditions of being a member of both the Managers group and the HR group.  Or, we could do it on the domain where we would create a central access rule that contains the defined conditions for group membership.  We would then include the rule in a central access policy that we could apply across multiple servers in our domain.  To test this, we could use proposed permissions to see how this new policy affects our resources without actually applying the change.  We could take this one step further by using claims.  We could create a claim on individual user accounts that gives them a unique identifier.  We could then use the unique identifier to make an expression that specifies the user is a member of the HR security group and has the associated claim to determine access permissions.  Think about how many groups and cases of unique permission administration we could eliminate.

In order to support Dynamic Access Control, a new Access Control List (ACL) editor has been included in Windows 2012.  The Enhanced ACL Editor allows you to incorporate the expressions created with the access control/permissions of the network resource.  This is the tool that allows you to create and bring together all the topics presented above.

Put a 2012 domain controller in a test environment and kick the tires of this concept.  Afraid of what you might break?  That’s what we’re here for. Call or click today for your free, network assessment.

AZS-3

 

Craig R. Kalty (CCIA, CCEE, CCA, MCITP:EA, MCITP:SA, VCP)
Sr. Network Consultant
Craig.Kalty@CustomSystemsCorp.com
© 2014 Custom Systems Corporation