Windows Server 2003 Migration: Tasks Part 2 – Planning

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

Windows Server 2003 Migration: Tasks Part 1 – Inventory

Know your environment. The very first task you need to do in a Windows Server 2003 migration is to update your inventory on your infrastructure. This does not mean only your Windows server 2003, this means your entire infrastructure. Why? Because you need to know exactly what you have, if there are any pitfalls, and if there are any synergies you can take advantage of. Just because a resource is not a Windows Server 2003, it does not mean it is exempt from the effects of the migration. In fact, you may need to update other resources in order to function with the results of the migration. You need to account for the following:

  • The quantity of Windows Server 2003 you have and their functions. How many are domain controllers? How many are just member servers?
  • The resources that are not Windows Server 2003.
  • Of the documented resources, the quantity of them still in use. You would be surprised how many organizations have orphaned servers and resources still in their environment because no one knew it was safe to remove them.
  • The hardware those resources reside on. Is the hardware still viable for today’s workloads? Is the hardware worth supporting?
  • The software/applications residing on resources. We need to know who owns it, is it still used, the resources required to install and operate the software, and if the software can be migrated.
  • The business units who use the resources. Talk to the people to find out if they actually still need the resources. Find out if they have any projects or plans to upgrade their applications that will facilitate the migration from Windows Server 2003.
  • The other resources or clients that need to communicate with the Windows Server 2003. For example, do you have a database or share on Windows Server 2003 that other servers are accessing?
  • The servers housing applications that can’t be migrated. Legacy software is one of the primary reasons we still have older servers with older operating systems. The software is still in use or is legally needed for archival purposes. There may be no upgrade path for the legacy system.
  • The people resources available. You will need to know if you have the staff with the needed experience and knowledge, the subject matter experts on the software applications, and the manpower-time needed for the project.

I won’t go into detail here on how to perform your inventory of your infrastructure. Various third-party vendors have products (inventory management systems) to help you. There are also tools on the Internet available to help with the task. Microsoft provides the Assessment and Planning Toolkit.

Once you have your inventory, you can start working on your plan. With the inventory and knowledge of the resources, you have the basis needed to determine priorities, tasks, resource assignment, scheduling and more. Now, we can move onto the planning: See our blog “Windows Server 2003 Migration: Tasks Part 2 – Planning” (available soon).

As always, I welcome your comments or questions. Please feel free to leave them below or email me directly.

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: Planning Considerations

In previous posts, we discussed the impending end-of-life of Windows Server 2003. Here, we’ll look at what to consider in planning the migration process from Windows Server 2003. Where does your organization fall?

  •  In a good position:
    •  You do not have any Windows 2003 servers in your infrastructure.
    •  You are well under way or have completed your Windows 2003 migration tasks.
    •  Your Active Directory level is Windows 2008 or higher and you have a handle on the few remaining Windows 2003 member servers.
  • There is a migration in your future:
    • Your Active Directory infrastructure level is 2003 (or lower).
    • You have multiple Windows 2003 servers in your infrastructure.
    • You have primary applications and data still residing on Windows 2003 servers.
    • You have only a few Windows 2003 servers.

If you believe a Windows 2003 migration is just another maintenance initiative assigned your IT department, you are probably taking this task too lightly and are setting yourself up for a big problem. For many organizations, this is one of those times where your infrastructure will undergo considerable changes. You can make the changes you need to get by or you can use this opportunity to modify your infrastructure to align with your goals. Either way, all of these are considerations that factor into your planning and execution:

  • Hardware – Use the existing or buy new?
  • Software – Use the existing or upgrade? What about compatibility issues and legacy software? Do we migrate to a new application completely?
  • Software licensing – What will change in licensing? We will probably need new operating system licenses. If we utilize tools like terminal services, we will need new Client Access Licenses (CALs). Upgrades to applications will most likely require updated application licenses.
  • Virtualization – If you do not have a virtual environment, this may be the time to start a virtualization initiative. If you have a virtual environment, what is the availability of resources?
  • Costs – There is a dollar amount tied to every IT initiative. Do you know your budget?
  • Time – How much time is the initiative going to take?
  • IT Staff – Do you have people with the knowledge and experience to perform the tasks?
  • User base – How will a migration affect the users? What parts of the migration affect which business units? Are there existing initiatives in our user base that tie in to our migration planning?
  • Training – Changes made to the infrastructure will require IT training. Changes made to the user offerings will require user training. New applications and tools incorporated into the migration will require training.
  • Security – If we do not change some systems, what are the consequences of leaving some Windows 2003 servers in the environment? How do the changes we may propose affect the security of our environment?
  • Infrastructure changes – If we add virtualization initiatives, new hardware initiatives, server consolidation, and application alterations, how will this affect our infrastructure? Are we moving to a different level of Active Directory? Do we have to change supporting servers and resources (SAN Storage, switch ports, recovery resources, etc.)?
  • Facility requirements – Will our infrastructure grow or shrink sue to the migration? If so, how will that affect our facilities? Do we require more or less rack space, power requirements, cooling, wiring, etc.?

Now that you have an idea of what you need to consider when planning your migration, we can take a look at the tasks needed to create and execute a plan. Those tasks can be found in next week’s post –  “Windows 2003 Migration: Tasks Part 1 – Inventory”.

As always, I welcome your comments or questions. Please feel free to leave them below or email me directly.

 

AZS-3

 

 

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

 

 

 

©2015 Custom Systems Corporation

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

Windows Server 2003 End of Life

On July 14, 2015, Windows Server 2003 Microsoft support will end. Meaning, after that date, there will be no more security fixes, hot-fixes, patches, or any other type of development for Server 2003 from Microsoft. It also means that if you have an issue and call in for Microsoft support, they will no longer open a support case for you. To find out the information from the source and to get ideas on how to move forward, click here. Over the next few months, we will be presenting blogs with information on migrating from Windows Server 2003. In this blog I am going to discuss a topic that is a major factor in migration.

Moving from 32-bit to 64-bit

One of the key points involved in moving off the Windows 2003 platform is going from 32-bit computing to 64-bit. 32-bit and 64-bit computing refer to a change in the instruction set for processors (CPUs) and how processors handle memory. Bits (binary digit) refer to the smallest units of computer data (a value of 1 or 0). As the number of bits in a computational value increase, the amount of data the value can hold increases. A 64-bit value exponentially holds a greater amount of data than a 32-bit. This difference is exhibited the most in physical memory addressing. The key differences of 64-bit computing over 32-bit computing is more memory. Memory limits in 32-bit Windows Operating Systems (OS) depended on the version in use and the 32-bit address space. Windows Server 2003 Standard had a limit of 4GB of memory, while Datacenter and Enterprise had a 64GB limit. In a 64-bit world, the Windows OS version still controls memory limits, but the 64-bit address bar has been raised. Windows Server 2012 Standard and above have a memory limit of 4TB. In fact, hardware is actually the primary limiting factor over software.

There is a Windows Server 2003 64-bit edition, but the adoption rate of that version was extremely low. The vast majority of Windows 2003 Server implementations were 32-bit. This happened for a number of reasons. The 64-bit server product was bleeding edge when it was introduced. Until Windows Server 2008, development for 64-bit products was not mainstream. Few software vendors factored in 64-bit compatibility in their code until Windows Server 2008. On the consumer side, 32-bit was the comfortable norm and 64-bit was factored in only when there were obvious gains. Requirements and advantages in Exchange and SQL were some of the primary factors for using the 64-bit version of 2003 over the 32-bit version. The number of users you could connect to one server through terminal services was greatly increased, but then you had to make sure that you were using software that worked in 64-bit terminal services.

It’s all about compatibility

So, what does all this mean in relation to migrating off Windows Server 2003? Compatibility. Will the software we have running in Windows Server 2003 work in 64-bit 2008 or 2012 servers? Will we have software drivers available on 64-bit that are as comprehensive as the ones we used in 32-bit systems? 64-bit servers are backward compatible and will run 32-bit applications, but not all 32-bit applications are 64-bit compatible. Applications with high resource demands probably moved towards 64-bit computing a while ago to take advantage of the increase in memory and processing power. However, we still have the issue of legacy software. We may only have licenses for a certain version of an application. We may need to pay for licensing of a later version. Or the licensing was based on the server OS. For instance, our 2003 Terminal Server CALs will not work with 2008 or 2012. We will need new licenses for that. What if there is no upgrade for that legacy system that will only work on a 32-bit system? All software issues will need to be researched and a plan developed to move forward.
Look for upcoming blogs, where we will discuss the research and testing needed, peripheral drivers (printers, scanners, etc.), SQL and Exchange requirements, backup solutions and more. Stay tuned and as always, please feel free to post your questions or comments below. You can also email me directly.

 

AZS-3

 

 

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

 

 

 

©2015 Custom Systems Corporation