Migrating basic Microsoft infrastructure. Part 1

Introduction

The theme of migrating the basic Microsoft infrastructure is not new. But there is very little complete and self-sufficient information on the conduct of this process, if not to say that there is no such information at all. On the Internet, you can find a lot of articles describing the migration process, but all these articles are some kind of stubs and do not reveal the full picture. If we talk about migration to new platforms, here there is even less information.

I would like to reveal this topic in a larger volume, to talk about the features of migration in real infrastructures. The specifics of the work of various information systems will be taken into account, how such systems need to be migrated, in what sequence.

One article to review the material is not enough (or it will be a very large article), so there will be several articles. The final volume of material is not yet known. I will write as far as possible, I will try not to delay with this process.

What will we consider the basic infrastructure, and what will be included in it?

• Active Directory directory service. By law, AD can be called a key component in the underlying infrastructure;
• DNS;
• DHCP;
• WINS;
• File servers;
• Print servers;
• Terminal servers and terminal server farms;
• DFS and its elements;

Now more and more organizations are using Exchange as a means of unified communications. Exchange is directly dependent on Active Directory, and the migration of the directory service will certainly affect the work of Exchange users. There is documentation on Active Directory migration, but this documentation does not describe the AD migration process in conjunction with Exchange. In turn, other documents describe the migration of Exchange, but it is not considered in conjunction with the migration of Active Directory. Approximately the same picture I observed on projects in which several architects participated - one for AD, the second for Exchange. Often their actions were not coordinated - the migration of the two systems was somewhat isolated, the features of joint migration were not taken into account. It turned out that one system (architect) interfered with another (another).
')
There are certain features of the migration of Microsoft SQL Server servers. Include in the migration and them.
What shall we consider as migration? We will consider the migration of resources from one or several forests to the target forest as migration. Such a model is most often encountered in practice.

The migration process itself is only half the battle (most likely even less). Migration process is complex, long, includes many tasks distributed in time, the implementation of which will allow to achieve some result, to achieve goals. I actually called the definition of a project. To carry out the project requires a certain approach. There are a lot of methodologies for project management, a large topic, this article will not be considered. Good recommendations for project management are given in the MSF (Microsoft Solution Framework) methodology. Some believe that this model is suitable only for developers and does not apply to infrastructure projects. In fact, it is not. The material of the methodology is well suited to infrastructure projects, you only need to plan a little. This methodology will not describe how and what to do, it will not have strict rules for conducting projects, but it will provide valuable advice that will help you to complete any project, not just IT.

Also standards will help in the design, for example, GOST.
Of these, you also need to select specific recommendations that will help you to complete the project successfully. Find GOSTs for automated systems here .
For example, I developed for myself a certain method, which is a hybrid of GOST and MSF methodology. I apply it in practice.

Some recommendations on project management, and more specifically on project team management, can be found in the Straustrup C ++ Programming Book, second and third edition. This book has a separate chapter on design.

Monitor the progress of the project will help you Microsoft Project. There is a good book by Gultyaev AK Project Management in Microsoft Project. I advise you to read.

Initial data.

What is our baseline data?

We have an initial infrastructure consisting of one forest and several domains.
The root domain name is source.com/SOURCE. Child domain is child1.source.com/CHILD1. Versions of domain controllers in source.com - Windows Server 2003 with SP2, in child1 - Windows 2000 Server with SP4. Domains have multiple users. Workstations - 2000, XP, Vista, Windows 7. There are servers Windows 2000 Server, Windows Server 2003 / 2008R1 / 2008R2.

Exchange 2003 version SP2 is installed in each domain. If SP2 is not installed on the Exchange server, you need to do this before migrating user mailboxes. Exchange 2010 supports mailbox migration only from versions of Exchange Server 2003 SP2 and Exchange Server 2007 SP2.

There are certain requirements for the versions of domain controllers when migrating mail to Exchange Server 2010 (or to Exchange 2007). About these features a little later.
We have already designed the target infrastructure and even implemented it. The target infrastructure will be the domain target.com/TARGET. Version of domain controllers Windows Server 2008 R2.
Exchange Server 2010 is installed on a separate server. All roles are installed on this server, more specifically, the roles of Hub, CAS and Mailbox. One of the servers in the source domain is currently responsible for handling external mail. After migration, this role will be taken over by another server in the new infrastructure - Exchange Server 2010 with the role of Edge Transport.

We will also have different types of servers in the source domain. We also have to migrate them to the new infrastructure. On the migration of servers a little later.

Integration.

Migration is a fairly long process and the process itself implies the long-term coexistence of the two systems, the old and the new.
Therefore, we need to integrate our current infrastructure with the target.

Name resolution

How to start the integration? Best with setting name resolution between infrastructures. We need migrated resources to resolve names of non-migrated resources, and vice versa. The most popular name resolution mechanisms in Windows networks are DNS and NETBIOS.
We assume that DNS servers are deployed on domain controllers. These DNS servers are served by the zone for their partition and the _msdcs.root_domain_les zone. Zones are integrated into Active Directory.
As a rule, only the resolution settings for DNS names between infrastructures are sufficient.

There are several ways to configure this interaction: forwarding, secondary zones, stub zones.

Consider the first method - forwarding:

In general, nothing prevents us from using this mechanism. First, we configure in the source domain forwarding for the target domain. For forwarding, we specify the nearest DNS servers of the target domain. What does the next one mean? As a rule, in a multi-domain environment, a separate domain is allocated for a regional site (in our case, it is child1.source.com). Now, of course, they try to move away from such a model and move on to a single-domain model. But do not consider the single-domain model as a rule. Sometimes it may not suit you. It all depends on the requirements. When migrating to a new domain, computers will register A-records on local domain controllers, that is, on domain controllers of the same physical site as in the original forest (assuming that we configured the DNS clients network card correctly; more on this later ). Therefore, it would be correct to configure the transfer to these local domain controllers.
In the target domain we do the same thing - we set up the transfer for the source domain between the nearest DNS servers.

If the source DNS servers are Windows 2000, you must use secondary zones or consider a name resolution method in conjunction with global transfers to the DNS servers of the target domain.
Starting with Windows Server 2008, it became possible to replicate transfer records between DNS servers. You can use this mechanism in order not to do the same work several times.

The second mechanism is the use of secondary areas:

Here we allow the transfer of the zone between the servers of the source and target domains. Create secondary zones: on the source DNS servers, secondary zones for the target domain, on the target domains for the source domain. As a master server we use the nearest DNS server. We set up the notification at changes. The number of changes before the alert is 1.

The third way is to use stub zones:

This functionality appeared in Windows Server 2003. With the help of stub zones, we can obtain information about authoritative DNS servers — NS and A records of servers serving the specified zone. Moreover, this information will also be dynamically updated.
In general, the method is excellent, but for our example it is only partially suitable. DNS servers from the child1 domain will receive NS / A records for all DNS servers of the domain target.com (cases with DisallowNSAutoCreation will not be considered). For name resolution, they will also contact one of these NS servers. When we migrate a computer to a new domain, it will register on the “new”, nearest DNS server. Still non-migrated computers will access the old DNS servers, and those in turn to some DNS server from the new domain. Which one? Will the new A-record for the migrated computer be able to replicate to this kind of DNS server? It is difficult to answer this question. Therefore, the stub zones from the old domain to the new one will not work for our configuration. But in the opposite direction we can use them.

Beginning with Windows Server 2008 R1, we have the ability to replicate zones of this type between DNS servers. It is worth taking advantage of this opportunity, especially since we have a Windows Server 2008 R2 forest target.

I would like to mention a few pros and cons of these three methods.
The forwarding method is fairly simple in configuration, and the zone transfer traffic is zero. But the traffic of requests is greater than that of the secondary zones. There are some limitations when migrating from Windows Server 2000: no support for conditional transfers. There are also problems with the relevance of the data. For example, if a record changes, say, the IP address of the computer has changed, then the changes will be reflected on the sending side only after the caching of the record has expired and at the second request. This also applies to the method with zones-plugs. What can not be said about secondary areas, where information is more relevant (subject to setting alerts when you change).

When using a secondary zone, the zone transfer traffic will be larger than the first and third methods, but the request traffic will be zero. The big disadvantage is the need to monitor the success of the transfer zone.

The option with stub zones has practically the same pros and cons as the shipment method.

Three ways. Which is better? The forwarding method is the simplest. Stub zones can only be used partially. The second method is more complex, which means that the probability of failure increases. I did not answer the question. Decide for yourself.
If there are firewalls between interacting systems (clients, DNS servers), we need to allow DNS traffic - 53 TCP / UDP.
Learn more about managing DNS servers at http://technet.microsoft.com/en-us/library/cc794771%28WS.10%29.aspx

Now a little about NETBIOS name resolution. The main method of resolving names in Windows 2000 and higher systems is DNS, but there are applications that still use NETBIOS functions and short names. Microsoft has taken a definite step to get rid of it. Now, starting with Vista / Win2008, NETBIOS functions are not supported. I hope that soon we will get rid of NETBIOS names forever. But the lack of support does not mean that such applications will not work in the forests of Windows 2008 R2. The use of NETBIOS names also continues.
There are three ways to resolve NETBIOS names: LMHOSTS files, broadcasts and WINS servers.

For LMHOSTS, you do not need to transfer anything, such files are migrated with computers. Another thing, if you are in the process of migration to rename the system. In this case, you need to manually tweak these files. We will not be able to influence broadcasting, so nothing can be done here. To migrate a WINS infrastructure, we can use one of the following methods:

1. Migrate your WINS infrastructure after migrating Active Directory resources:
   
2. Configure replication between new and old WINS servers, switch computers to the new infrastructure before migrating AD resources:
   
3. Like the second method, but we switch computers after migration to a new forest:
   

The first and third methods are good because we do not encounter problems of relevance and convergence of data. All computers are directed to the same WINS servers (migrated and non-migrated computers), which means there is a single point, both resource updates and their resolution. Then we will have to configure replication between the infrastructures (or for the third, we have already done this) and, when all the resources have been transferred, we need to switch computers to new servers. If you switch all the computers at once, you will surely run into some problems with name resolution. To guarantee the switching of all computers is hardly possible in a large infrastructure. And if you switch portions, the migration time will increase.

It is better to run into problems on a smaller scale and solve them (prevent) as they become available. This is the second way. We first set up replication between the old and the new forest, and then, before the migration, in portions (slots), we switch computers to the new WINS servers. In this configuration, non-migrated resources look at some servers that are migrated to others. There is a problem with the latency of data replication between these systems. But, as I said, new systems prefer DNS, so we are unlikely to run into problems. And if we collide, then, most likely, on a small part of computers.

We have the ability to integrate DNS with WINS - to make WINS lookup for the DNS zone. Do I need to do this for migration? Better not worth it. This is an unnecessary complication, which is fraught with errors and the probability of failure of complex systems is still greater than that of simple ones. If we talk about real problems, then errors may occur during authentication using the Kerberos protocol. And that's why. For example, a user requests some service by short name - SERVICE01. A certain suffix is ​​substituted and the name is long - SERVICE01.target.com. Then the request is sent to the DNS server, in which the WINS zone is configured for the target.com zone. If DNS does not find the specified record in the target.com zone, it will discard the domain tags and ask WINS for the record SERVICE01. WINS will respond with an IP address. But from what domain is this record? WINS is a flat name system, and therefore unknown. The DNS server will return the response to the user: SERVICE01.target.com = IP address. The IP address is likely to be correct - you can start pings. But what if the user wanted to access the service from the old forest - service01.source.com. This is where problems may arise when searching for a service by ServicePrincipalName. As a result, problems may arise with Kerberos authentication.

Of course, this problem may not appear. It all depends on the implementation of applications and operating system. But it is better to prevent such errors in advance, especially the category of such errors is difficult to localize.

What to do if we decide to configure replication of the WINS base between the infrastructures? Should the database be replicated only between the nearest WINS servers or will it be mixed replication?

Look at your current replication model and do the same. If you have a multi-domain environment and replication is configured between servers from different domains, then you have no problems with duplicating NETBIOS names. If there is, then it is worth considering whether there will be problems when migrating to a single-domain structure. In this configuration, you can use replication via the trunk.

If replication is used only within the domain, then configure replication within the physical site - between servers from the old domain and servers of the same site of the new domain.

Requirements for opening TCP / IP ports used by WINS servers are http://technet.microsoft.com/ru-ru/library/cc784026%28WS.10%29.aspx .
Learn more about managing your WINS server at http://technet.microsoft.com/en-us/library/cc739183%28WS.10%29.aspx .
Name resolution should be given special attention. Moreover, not only during migration. Errors related to name resolution account for 80-90% of the total (if you do not take into account the mistakes of IT professionals).
This does not end the name resolution setting. We will continue to discuss this topic.

In the next article we will continue the integration of our infrastructures.