Tag Archives: migration

Server 2012 or 2016: To Upgrade or Wait

Posted on by

To upgrade or wait?

Once again, we are faced with the age-old IT question – should we upgrade or wait? In this case, the question refers to Windows Server — “Should we go to 2012 now or should we wait?”  As in most cases within IT, the answer depends on the situation and is different from environment to environment.  Let’s look at the timeline that bring up this question:

  • Windows Server 2016 is expected to be released  first quarter 2016.
  • Windows Server 2012 R2 released in October 2014.
  • Windows Server 2012 had a general availability release back in September 2012.
  • Windows Server 2008 R2 has a tentative End of Life (EOL) set for 2020.

Currently, Windows 2008 R2 makes up the majority of the server workloads in use today.  Many organizations have barely started working with 2012, if at all.  Most organizations are still operating Active Directory at the 2008 level.  Some are still on Windows Server 2003, even though it has already hit EOL.  The past repeats itself because we have again hit a point where the most utilized version of a Windows software is going to be two or more generations behind the latest release.  Server 2012 adaptation increased when R2 was released and particularly when Server 2003 hit EOL and companies needed to migrate off that platform.  Timing and other factors went into the slow adaptation of Server 2012.  However, Server 2012 suffered from the same issue Windows 8 did – the interface.  Server 2012 is a solid product, but the interface turns off so many IT professionals who have to live in it day-to-day.  The interface is based on the Metro Interface used in Windows 8.  The Metro Interface was designed with touch screens and tablets in mind.  How many IT professionals have touch screens available or use tablets when connecting to their Windows servers?  Yes, you can put a start menu in 2012 with a third-party product.  But how many of us are against the cluttering of our servers with unnecessary software installations?

Given what was just stated, let’s get back to the question at hand.  Should you got to Server 2012 now or wait?  The answer depends on your organization’s needs, plans, and project timeframes.  At this point, the most compelling reasons to install server 2012 right now is if you are installing or upgrading to the latest versions of a particular application, you are still on server 2003, or a company mandate is in place.  Here are some reasons to wait for server 2016:

  • At this point in the year, if you have not budgeted for an upgrade/migration project for this year, then you can put it in the budget for next year.
  • Server 2016 has an interface that is based on Windows 10’s interface. Yes, it has a start menu.
  • Going to server 2012 R2 in the near future will immediately put you one version behind.
  • Along with Server 2016, Exchange, SQL, and SharePoint 2016 will be released as well.
  • The preview builds have had favorable reviews.
  • Needed improvements in Hyper-V.
  • If you migrate now, how long before you will need to migrate again.

Let’s look at the reasons against waiting for Server 2016:

  • Keep in mind that even though the release is expected first quarter, it is not a good thing to have your production environment on the bleeding edge. I usually advise my clients that adapting a new version of a software should be held off for a few months after the release at the least.  The major issues will most likely be found and resolved within the first few months.  I usually advocate waiting until the equivalent of the first service pack comes out.
  • If you are still on a 2003 environment, you are waiting too long and sitting on vulnerabilities that will no longer be remediated.
  • Application compatibility. We are looking at a new operating system.  You know there are going to be applications that are not compatible with it.  Even if a piece of software proves compatible, you may still need to wait until the vendor says it supports the installation.
  • Knowledge and the ability to support the features. This is a new Operating System.  You can relate what you know about previous versions of Windows Server, but there will definitely be new subject matter to learn.  Features like containers will need some research and knowledge.  If you are not comfortable with PowerShell, you better get comfortable.

In short, if you are not on server 2012 at the moment, are off of Server 2003, and you can wait about eight months, then consider waiting for Server 2016 to do your migration.  The nice thing I have seen so far, is that you can treat 2016 like another version of Windows Server with improvements for what you know and use now.  However, it is the new features and concepts that will make it worth the wait.  I will be posting a blog or two (or three) concerning the release of Windows 2016 in the next few months.  I usually write blogs like this one for a wide range of readers involved in IT from the technical to the not-as-technical.  The future blogs on Windows 2016 will be more technical.

Feel free to post any questions or comments below or reach me directly by email.

 

AZS-3

 

 

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

 

 

©2015 Custom Systems Corporation

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

Windows Server 2003 Migration: Tasks Part 3 – Build and Test

Posted on by

windows server 2003 R2In Part 2, we created a plan that maps out the migration from Windows Server 2003. Now we are at the point where we need to build what we designed. Notice how in all the blogs concerning decommissioning 2003 that I use the words ‘migrate’ and ‘migration’ and not upgrade? I probably should have discussed this sooner, but there is no upgrade. You cannot upgrade 32-bit Windows 2003 to 64-bit 2008 R2 or 2012 R2. No matter your plan and budget, you will need to perform a fresh install on at least one server to start the process. Also, it would be wisest to go to 2012 R2 for many reasons (particularly not having to repeat this process when 2008 reaches end-of-life). For some migration paths, you may need to install at least one 2008 server to go from 2003 to 2008 and then to 2012.

The best place to start would be a test/development environment. We know from experience that there are many smaller shops out there that do not have the budget to create a development environment. Most of them are going to rely on the expertise of their staff or outside services to get their environment from where it is now directly to an updated infrastructure without performing a lot of tests. For those environments, remember to at least do extensive planning and research beforehand to mitigate issues. For those that can build a development environment, the best way to do it is virtualization (there I go again using that word). Remember that you can make a virtual server host out of various hardware platforms. You can even install a robust hypervisor for free. To give you an example, my laptop has an extra drive that I swap instead of the DVD drive. I then manually boot to the extra hard drive where I have XenServer hosting over a dozen VMs. Is it powerful? Not really, but I can run my demo environment from it. The point is we don’t need to break the budget to make a development environment. We may not even need to touch any of the budget. If you did budget for a new virtual environment or to extend an existing one, here is where you can start utilizing that new investment. P2V (physical to Virtual) machine images of your existing infrastructure servers. From there, you can fire up a new virtual machines (VMs) housing 2012 R2 and/or 2008 R2. Once you have the test environment, take snapshots of all the VMs before making any changes. Now you can begin the process of converting your virtual infrastructure in a development environment. If you run into issues, you can utilize the snapshots to reset the environment and try again. Take detailed notes of all the steps and pay attention to any potential problems. Once you have a clear plan with detailed notes, you are less likely to run into the unexpected when updating your production environment.

So, what exactly are we testing in our development environment? There are basic services that almost every shop is going to be utilizing. Active Directory, DNS, and DHCP are the three most common services we will need to migrate to another server. The good news is that detailed directions from Microsoft and other experts can easily be found on the web. Some organizations are going to have the basics and some are going to have more services in use. For instance, some organizations may utilize Terminal Services. Migrating that to Remote Desktop Services (RDS) will be a project in itself (though a worthwhile one).

Here is an example list of services you may/will need to test:

  • Basic services:
    • Active Directory (AD)
    • Group Policy
    • Domain Naming Systems (DNS)
    • Dynamic Host Configuration Protocol (DHCP)
  • Extended services:
    • Certificate Services and Public Key Infrastructure (PKI)
    • Terminal Services
    • Distributed File Services (DFS)
    • Internet Information Services (IIS)
    • Network Load Balancing (NLB)

Each organization is different, so they may have some or all of the items from the above list. A lot of organizations will have more to add to the list. Aside from these services that come in a Windows server, we will need to test hosted applications. This set of blogs has been pretty much focused on the Active directory side of the migration, but what about applications? If you have Exchange, SQL, or another enterprise application hosted on a 2003 server, you are going to need a separate project just to migrate those applications. This may be the opportunity to move from in-house mail services to a cloud-hosted solution like Office 365. It is possible to focus on upgrading our Active Directory infrastructure first and saving the applications hosted on 2003 servers for a later project. However, research the applications to make sure they will still function in an updated AD infrastructure. If not, that is one of those symmetrical projects you will need to have in your plan.

The next step will be implementation into production. At this point, we are ready. We have performed tests in our development environment, gained experience in the tasks, created detailed instruction sets, and realized modifications needed in our plan.

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

Windows Server 2003 Migration Resources

Posted on by

Microsoft will end support for Windows Server 2003/R2 on July 14, 2015.

Now is the time to migrate.

Here are some links and resources to help as you prepare for your Windows Server 2003 migration. Be sure to bookmark this page to avoid missing new resources as they are added.

Windows Server 2003 migration

– Understand what end of support means, directly from Microsoft, via Custom Systems Corporation.

Great resources from our own blog:

Upgrading Windows Server 2003 Active Directory

This is a basic guide to help walk you through the upgrade of  Server 2003 Active Directory to Server 2012 R2.

Migrating from Windows Server 2003: 64-bit vs. 32-bit

This this post, we’ll explain  one of the key points involved in moving off the Windows 2003 platform – moving from 32-bit computing to 64-bit.

Windows Server 2003 Migration: Planning Considerations

Where does your organization fall today, in planning the migration process from Windows Server 2003.

Windows Server 2003 Migration: Tasks Part 1 – Inventory

Just because a resource is not a Windows Server 2003, it does not mean it is exempt from the effects of the migration. In this first task, review your current inventory to prepare for server migration.

Windows Server 2003 Migration: Tasks Part 2 – Planning

Now that we have our inventory, it is time to plan our Windows Server 2003 migration.

Windows Server 2003 Migration: Tasks Part 3 – Build and Test

Now we need to build what we’ve designed.

Windows Server 2003 Migration: Tasks Part 4 – Implementation

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.

Finally…

Be sure to bookmark the Windows Server 2003 Countdown Clock on our site. You’ll also find great resources directly from Microsoft here. The network services professionals at Custom Systems are trained to perform the tasks outlined in our blogs, necessary for your organization to migrate from Windows Server 2003. You can reach our sales team by calling us at 800.539.3523 or by email.  Please feel free to leave any questions or comments below.

Windows Server 2003 Migration: Tasks Part 2 – Planning

Posted on by

Dusit PLANNINGIn Part 1, we discussed taking inventory. Now that we have our inventory, it is time to plan our Windows Server 2003 migration. The planning phase is very critical. This is where you are going to make major decisions that will affect your infrastructure going forward. We could do a straightforward migration going server to server or we could use this opportunity to make needed or desired changes to the infrastructure. Moving from Windows Server 2003 will make news technologies and advancements available. You do not have to create a plan from scratch. There are a number of tools we can use. For instance, Microsoft has the Assessment and Planning Toolkit. The web is full of helpful tools that you will have to log onto. Also, open your favorite browser and search engine to find what you need (say, a blog like this).

For our planning phase, we need to factor in the following:

  • Inventory – We took an inventory of our infrastructure in Part 1. We now need to assess that inventory.
  • Budget – How much we can spend determines what we can do to perform the migration. If we can afford to put up a new virtual environment or build on an existing virtual environment, then we virtualize. If we can only afford to utilize the hardware we have, then this is a rolling migration.
  • Man-power – The experienced resources available to work on this project and how much of their time they can allocate/dedicate.
  • Timeline – Given how long we have to complete this task, we can determine what we can accomplish.
  • Infrastructure and environment – The condition of our infrastructure and the environmental resources may require modifications to accomplish this project. If you are adding new servers, you may need new racks, more space, more cooling, and more power.
  • Symmetrical Projects – Those projects we can get done in conjunction with this project (i.e. virtualization) or those projects going on that could be impacted by our migration project.

Given the factors above, here are the general tasks in creating your plan:

  • Determine the project manager. Make sure you have someone who is dedicated to seeing this project through and can coordinate the plan.
  • Put the inventory into categories that make sense to your team and then prioritize the categories. The inventory facilitates our assessment of what we have.
  • Given the assessment and factors listed above, we can determine our needs, tasks, and what we can feasibly accomplish.
  • Determine the goals:
    • Are we migrating everything?
    • What are we migrating within our deadline? What can be migrated at a later time?
    • Are we trying to migrate and utilize the existing hardware or are we moving to new hardware?
    • Where will the supported applications reside?
      • New physical server?
      • Virtualization?
      • Moving to cloud services?
  • Determine your timing – Take your priorities and determine what can be accomplished within the allotted time frame and what needs to be done at a later time.
  • Map out the target destinations for the items you are migrating (i.e.virtualize, move to the cloud, upgrade, decommission, etc.)
  • Given the priority and desired outcome, determine how much time each task needs. Where possible, leave time for the unexpected. Try not to make your timeframes to tight. (Don’t read this out loud: If you want, use the Engineer Scott method. Give a time frame you know you can beat so you look good.)
  • Map your resources to your task. Determine the best available candidate(s) for each task.
  • Develop your timeline. Take the information and priorities you have gathered and map the tasks with a start date and time, duration, and an expected end date.
    • Include allowances for acquiring new resources. For instance, that SAN you ordered for the virtual environment may take three weeks to deliver. Use other tasks to fill the gaps where you are on hold. Even if they are a lower priority.
    • Include research time for each task. It does not hurt to admit that there are tasks your people are not sure how to accomplish. I would not want someone to try and migrate my DHCP from server 2003 to server 2012 without having experience or at least proper instructions. Within the planning documentation, note where to find the instruction sets.
    • Don’t oversaturate a resource. We all have environments where certain people will wind up being the subject matter expert for multiple tasks.
  • Document everything.

I know that I have greatly simplified the information listed above. The goals of the blogs in this series are to get you thinking, give you a general outline, and help keep you moving. I cannot stress enough that you need to be very detailed with your resulting planning. Your plan is what will be visible to your team and your management. You will most likely be held to the plan you publish. Proper planning will take out guesswork, cut down on surprises, help you handle the unexpected, and keep things running smoother.

In the next blog for this topic, we will look into our next step: ‘Build and Test.’

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.

AZS-3

 

 

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

 

 

 

©2015 Custom Systems Corporation

Microsoft Hyper-V Migrations

Posted on by

We’ve recently had to migrate a few Microsoft Hyper-V Virtual Servers from one host server to another.  This is useful if you have purchased new server hardware, but want to keep your current virtual servers as they are.  Another purpose is in the event of a partial hardware failure – for example you have lost more than one hard drive.  The ability to move virtual machines (VM) from one host server to another is a built-in feature of Microsoft Hyper-V, but requires several steps.

Here are a few tips:

  1. Take a full backup of each VM before you do anything else.
  2. I use the term ‘migrate’ loosely.  What we are actually doing is exporting a VM from one host to another.  You cannot simply copy and paste virtual servers.
  3. Make sure you do not have any snapshots.  Otherwise you won’t be able to export your VMs.  I STRONGLY urge my customers not to use snapshots – but if you have them, they must be merged before a migration can begin.
  4. Your virtual network settings need to match on both your old and new host servers.
  5. We have had issues losing the Server Identification Number (SID) when moving virtual database servers.  It can be sort of hit-or-miss. This is why backups are so important.
  6. If possible, export your virtual servers from your old server directly to the new storage location.  There is no need to move them twice and by doing so, you are eliminating possible failure points.
  7. After you have imported your virtual servers onto your new hardware, test each server before deleting the old copies.  Use caution not to have both the old VMs and new VMs running at the same time.
  8. Although I suggest migrating Hyper-V 2008 servers to another 2008 server, it is possible to migrate from a Hyper-V 2008 server to a Hyper-V 2012 server.  We will cover that in another article.  (Read as: after I have a chance to try it!)

ChaseChase Reitter
Network Consultant
Custom Systems Corporation
Chase.Reitter@CustomSystemsCorp.com
© Copyright 2013-20114 Custom Systems Corporation