Время на прочтение5 мин
Количество просмотров202K
Не секрет, что окончание поддержки Windows Server 2003 все ближе. День Х назначен на 17 июля 2015 года, а значит остается все меньше времени, чтобы успеть перевести свою инфраструктуру на более современные версии операционной системы. На Хабре мы уже делали несколько анонсов об окончании поддержки, на портале Microsoft Virtual Academy опубликован курс по материалам Jump Start, есть перевод статьи о переносе файлового сервера. В этой статье будет рассказано о миграции Active Directory и приведен пошаговый алгоритм, которым поможет вам при реализации переноса.
Перенос Active Directory с Windows Server 2003 на Windows Server 2012 R2 является одной из первоочередных задач, которые необходимо решить в процессе миграции.
На самом деле, перенос Active Directory не несет в себе каких-либо сложностей. Нужно выполнить лишь несколько шагов, о которых будет подробно рассказано далее.
Сначала выполним небольшую настройку на контроллере домена с установленной на нем Windows Server 2003. Обязательно проверьте, что для существующего домена и леса в качестве режима работы (functional level) выбран Windows Server 2003.
Для того, что изменить режим работы домена и леса необходимо запустить оснастку Active Directory Domains and Trust. Для изменения режима работы домена щёлкаем правой кнопкой мыши по домену, для режима работы леса – по Active Directory Domains and Trusts. Выбираем Raise Domain Functional Level и Raise Forest Functional Level соответственно.
В обоих случаях режим работы должен быть установлен на Windows Server 2003.
Следующим шагом нам нужно добавить к нашей сети второй контроллер домена под управлением Windows Server 2012 R2. Для этого на сервер с Windows Server 2012 R2 устанавливаем роль Active Directory Domain Services.
После установки добавим новый контроллер домена к существующему домену. Для этого нам нужно будет использовать учетную запись, которая входит в группу Enterprise Admins и обладает соответствующими правами.
Необходимо указать, будет ли этот сервер выполнять роль DNS сервера и глобального каталога (Global Catalog – GC).
На экране Additional Options нужно указать с какого контроллера домена будет выполнена репликация на существующий. Нужно выбрать контроллер домена под управлением Windows Server 2003.
Для установки домена необходимо выполнить подготовку леса, домена и схемы. Если раньше для этого обязательно нужно было запустить команду adprep (причем сделать это надо было до начала конфигурации домена), то теперь эту задачу берет на себя мастер конфигурации ADDS, и подготовка может быть выполнена автоматически.
Далее нужно дождаться завершения установки и перезагрузить компьютер. В итоге, вы получите контроллер домена с установленной на нем Windows Server 2012 R2.
Теперь в оснастке Active Directory Users and Computers мы можем увидеть, что в нашей сети есть два контроллера домена.
После того, как выполнены предварительные шаги, мы можем перейти непосредственно к переносу Active Directory. Выполнять необходимые действия мы будем на контроллере домена под управлением Windows Server 2012 R2 в следующем порядке:
- Перенос роли FSMO (Flexible Single Master Operations)
- Изменение контроллера домена Active Directory
- Изменение Мастера схемы (Schema Master)
- Удаление контроллера домена под управлением Windows Server 2003 из глобального каталога (Global Catalog)
1. Перенос роли FSMO (Flexible Single Master Operations)
Для того, чтобы перенести роль FSMO, открываем оснастку Active Directory Users and Computers, щёлкаем правой кнопкой мышки по нашему домену и в появившемся подменю выбираем Operations Masters.
Нам нужно перенести роль хозяина операций. Для этого на каждой вкладке во вновь появившемся окне нажимаем кнопку Change и переносим роль с 2003 сервера на сервер под управлением 2012 R2.
Подтверждаем операцию переноса и дожидаемся ее благополучного завершения. Не забудьте проверить, что в итоге роль хозяина операций теперь находится на сервере под управлением Windows Server 2012 R2:
2. Изменение контроллера домена Active Directory
Теперь переходим к изменению контроллера домена Active Directory. Открываем консоль Active Directory Domains and Trusts, щёлкаем правой кнопкой мышки по лесу и выбираем пункт Change Active Directory Domain Controller.
В новом окне выберите пункт This Domain Controller or AD LDS instance и укажите сервер под управлением Windows Server 2012 R2.
Теперь снова щёлкаем правой кнопкой мышки по лесу и выбираем пункт Operations Master.
Переноси роль хозяина операций именования домена, нажав Change.
3. Изменение Мастера схемы (Schema Master)
Теперь приступаем к изменению мастера схемы (Schema Master). Запустите командную строку с правами Администратора и введите команду regsvr32 schmmgmt.dll
С помощью этой команды происходит первичная регистрация динамической библиотеки DLL, которая является обязательной для оснастки Active Directory Schema.
После того, как команда выполнена, можно закрыть командную строку, запустить консоль MMC и добавить оснастку Active Directory Schema (для этого выберите File > Add/Remove Snap—in).
В этой же консоли MMC щёлкаем правой кнопкой мыши по Active Directory Schema и выбираем Change Active Directory Domain Controller. Аналогично действиям, которые мы выполняли в пункте 2, в новом окне выберите пункт This Domain Controller or AD LDS instance и укажите сервер под управлением Windows Server 2012 R2 и нажмите ОК. Появится предупреждение о том, что оснастка схемы Active Directory не подключена. Нажмите ОК для продолжения.
Теперь снова щёлкаем правой кнопкой мышки по лесу и выбираем пункт Operations Master. Для переноса роли хозяина схемы в новом окне нажмите Change.
Теперь можно закрыть MMC консоль, открыть оснастку Active Directory Users and Computers и убедиться, что данные успешно реплицированы на ваш новый сервер под управлением Windows Server 2012 R2. Имейте ввиду, что процесс репликации может занять некоторое время (все зависит от количества объектов Active Directory, которые нужно реплицировать).
4. Удаление контроллера домена под управление Windows Server 2003 из глобального каталога (Global Catalog)
Осталось удалить контроллер домена под управлением Windows Server 2003 из глобального каталога. Для этого открываем Active Directory Sites and Services, разворачивает папку Sites, затем Default-First-Site-Name, затем Servers и, наконец, разворачиваем оба сервера.
Щёлкните правой кнопкой мышки по NTDS Settings для вашего старого сервера под управление Windows Server 2003, выберите Properties. Во вновь появившемся окне уберите галочку с пункта Global Catalog и нажмите ОК.
В Active Directory Users and Computers контроллер домена на Windows Server 2003 теперь не является глобальным каталогом.
Осталось проверить, что теперь роль FSMO запущена на Windows Server 2012 R2. Для этого в командной строке, открытой с правами Администратора запускаем команду netdom query fsmo
На этом миграция Active Directory завершена. На компьютере под управлением Windows Server 2003 запустите dcpromo (кстати, в Windows Server 2012 R2 dcpromo нет) для того, чтобы понизить роль компьютера с контроллера домена. Если после этого посмотреть на консоль Active Directory Users and Computers, вы увидите, что остался только один контроллер домена – под управлением Windows Server 2012 R2.
Надеюсь, что эта статья будем вам полезной!
Полезные ссылки
- Попробовать Azure бесплатно на 30 дней!
- Изучить курсы виртуальной академии Microsoft
- Основы компьютерной безопасности
- Основы построения доменной сети. Часть 2
- Модернизация инфраструктуры организации с помощью Windows Server 2012 R2
- Переход с VMware на Hyper-V
- Основы построения доменной сети
- Бизнес и облако: лучшие практики решений
- Скачать пробную версию Windows Server 2012 R2
- Загрузить бесплатную или пробную Visual Studio
So as the life of Windows 2003 is finally coming to an end, I am seeing a big push for domain upgrades and the pitfalls that come with it. So I created a walkthrough to help that process go smoother and to help avoid the common issues. I included DHCP in this posting due to the many servers I see that are Domain Controllers and DHCP servers. If you are getting DHCP from another device like another server or router, the steps outlined are still applicable as far as changing the DNS server to point to the new DC before you decommission the old DC.
My environment at the start of the migration:
DC01.matrix.local
OS: Windows 2003 x86 SP1
IP: 192.168.90.1
Subnet: 255.255.255.0
GW: None – completely isolated environment
DNS: 192.168.90.1
Services for clients – DHCP, DNS, Active Directory
DHCP looks like:
Note: Excluded the range 192.168.90.1 – 192.168.90.50 as this is how I would normally deploy DHCP – Statically needed IP Addresses would be within the range that was excluded. Examples would be Routers, Servers and Printers.
DNS zones look like this:
Really everything at this point is default with the exception that I added the reverse zone. Matrix.local and the reverse zone replicated to all DNS servers in domain and the _msdcs zone is replicated to all dns servers in forest.
Client01.matrix.local
OS: Windows 8.1 (I selected this one as client machines tend to get the new stuff especially now with the BYOD or Bring Your Own Device movement)
IP: Dynamically assigned by DC01
Subnet: Dynamically assigned by DC01
GW: None – completely Isolated environment
Client01 is joined to the domain and is able to authenticate, access dns, and gets an IP – the user that is authenticated is Mr. Testy Tester or Matrix\TTester
DC02.matrix.local
OS: Windows 2012R2
IP: Dynamically assigned by DC01
Subnet: Dynamically assigned by DC01
GW: None – completely isolated environment
DNS: 192.168.90.1
Okay, let’s review some configuration items to get us started.
Active Directory:
It’s always best to review the health of active directory to make sure there is no gotchas to sneak up on you. If not installed and you have the install cd for 2003 install the support tools from CD:\Support\Tools\SUPTools.msi or downloaded from http://www.microsoft.com/en-us/download/details.aspx?id=15326.
- From a command prompt run netdom query fsmo as below:
This lets you know where the fsmo’s are located – If any of these has an error where it is unable to locate the role holder, stop because you will need to probably need to seize the role and perform a metadata cleanup.
Seize FSMO Role – http://support.microsoft.com/kb/255504/en-us - Run is a “net share”
These two shares are where your group policies are stored and if they are missing your DC will not act as a domain controller and will not authenticate users.
- Run a repadmin /showreps – if you currently only have 1 dc I would expect the output to look like:
-
Check the Eventlogs for errors relating to Active Directory, File Replication Service, Netlogon, Time
- Directory Service
- System
- File Replication Service
If everything appears normal then we are ready to introduce our 2012 R2 server into the environment. If there are errors stop now and investigate!
Setup the new 2012 R2 Server
- Statically set the IP Address of the server
My IP Address will be 192.168.90.2 / Subnet will be 255.255.255.0 / No Gateway/ DNS 192.168.90.1
Note:
I don’t have a gateway because my test environment does not have internet access, your environment likely does so you will likely have a gateway. - Rename the server and join the domain with your 2012R2 server
- Once you click OK, you will be prompted for credentials – put the credentials of your domain admin account in and press ok.
If you get a message like:Once the server reboots, sign in as the domain admin account
Note: If you are using the default Administrator account, sign into Windows with Domain\Administrator as Windows by default will change the domain to local when it detects a local account with the same name. - Once Server Manager comes up, Click Manage, Add Roles and Features
- The Add Roles and Features Wizard will come up – Click Next
- Make sure Role-based or feature-based installation is selected and click next.
- Verify your sever is the selected server then click next
- Select Active Directory Domain Services, on the popup click Add Features, then Click next
- Click next on the features page
- Click Next on the AD DS page
- Then Click Install
Promote Server to a Domain Controller
- Once that completes Click Close, You will be back on the Server Manager Screen – Click the Flag on the Top Menu and select the link to promote the server to a domain controller
- This will start the process to make this a domain controller
Make sure the Domain information, Add a domain controller to an existing domain, and the current domain administrator is correct.
- This would be a good time to make sure that the user doing the promotion is a member of the Enterprise Admins and Schema Admins group on the 2003 domain controller.
Being a member of these 2 groups will allow you to promote the DC into the domain and perform the necessary schema updates needed for 2012 R2.
- Clicking next on the Active Directory Domain Services Configuration Wizard I received an error
Fixing this issue is fairly simple, we just need to raise the Domain and Forest Functional to 2003
- Open Domains and Trusts on the 2003 DC
Right click on the Active Directory Domains and Trusts, Select Raise Forest Functional Level
If you get a message like:
You will need to do the domain functional level first.
- Open Active Directory Users and Computers
Right click on the domain in the left pain and select Raise Domain Functional Level
Select Windows Server 2003 from the dropdown and click Raise
- Once that completes, and if you have more than one domain controller, replication completes. Go back to Domains and Trusts
Right click and raise Forest Functional Level
Again if there are more than one domain controller it may take a minute to replicate, if not than this change is really quick.
- We are now ready to try the promotion process again, Click Next on the deployment configuration
Note: We get a warning stating that there are no 2008 domain controllers in the domain so this server will be unable to become a read-only domain controller. This is just a warning and nothing to be concerned about.
- Type in the Directory Services Restore Mode password and click next
- Under DNS option there is another warning about DNS delegation, ignore that and click next
- Additional Options: Click Next
- Under Paths, Modify any paths or accept the defaults and click Next
- Under Preparation Options click Next
- Under Review Options, Click Next
- After the Prerequisite Check Runs Click Install
- After install is clicked the forest and domain will be prepped for 2012. Once the install is completed and the server reboots and will then come up as a domain controller in your domain.
Verify Active Directory on the New Server
- One of the first things to validate is that the Netlogon and Sysvol shares
Run net share from PowerShell
- Run repadmin /showreps – notice we get a lot more information this time
- Lets also check that on the 2003 server
- Lets check DNS on the new 2012R2 server
What you want to look at here is to make sure that both DC’s have SRV records inside dns. SRV records is how clients locate available DC’s in which to use for authentication. You can also validate that the same records appear on the 2003 server.
- Check the event logs
- Open Active Directory Users and computers, create a test user validate that it replicates from 2012 to 2003, then rinse and repeat from 2003 to 2012
- Open Group Policy Management console and validate all group policies that are expected to be there are there
Decommission 2003 Server
-
Transfer the FSMO roles to new server
- PDC – http://technet.microsoft.com/en-us/library/cc739670(v=WS.10).aspx
- RID – http://technet.microsoft.com/en-us/library/cc781063(v=ws.10).aspx
- Infrastructure – http://technet.microsoft.com/en-us/library/cc782485(v=ws.10).aspx
- Domain Naming Master – http://technet.microsoft.com/en-us/library/cc738685(v=ws.10).aspx
- Schema – http://technet.microsoft.com/en-us/library/cc759254(v=ws.10).aspx
-
Transfer DHCP services to the new server
- Install the feature on the 2012R2 server
- In Server Manager, Click Manage, Add Roles and Features
- Role-based or Feature-based – Click Next
- Validate 2012 is selected Click Next
- Select DHCP from the list, Click Add features from the Pop-up, Click next
- Click Next
- Click Next
- Click Install
-
Configure the scope for DHCP (I deliberately broke this up into three distinct steps, Setting up DHCP on the new server, deactivating the old server and Activating the new server – this is to allow the cutover to be planned according to a migration schedule. In an actual migration I would lower the lease times to something really short 2 days to allow clients to renew their leases from the new server without administrative intervention)
- Click Complete DHCP configuration
- Click Next
- Select Skip AD Authorization (We already have an Authorized DHCP server)
- Select Commit
- Select Tools, DHCP
- In DHCP MMC, Drill down to IPv4, Right Click and select New Scope
- Under New Scope Wizard select Next
- Name your new Scope and click Next
- Set your Range up and Click Next
- Set up your Exclusion Range
- Setup your Lease Duration Time
- Select Yes to configure the scope Options, Select Next
- Set your gateway address
- On Domain Name and DNS Servers, Remove any old DNS servers so that only the new 2012 Server is listed
- Leave Wins Blank, Click Next
- On Activate Scope, Select No, I will activate this scope later, Then Select Next
- Click Finish
- Click Complete DHCP configuration
-
Deactivate the 2003 DHCP Server
- Right Click the Scope and Select Deactivate – I am deactivating the scope – in case the server is reathorized later – the server will not automatically start handing out IP’s
- Right Click the Server and Unauthorize
- Right Click the Scope and Select Deactivate – I am deactivating the scope – in case the server is reathorized later – the server will not automatically start handing out IP’s
-
Turn on DHCP on the new 2012R2 Server
- In the DHCP MMC, Right Click the Server Name and select Authorize
- Right Click the Scope and Select Activate
- DHCP Console should appear similiarly to:
- In the DHCP MMC, Right Click the Server Name and select Authorize
-
Validate clients receive DHCP Address from the new server
- Check current settings, notice that the lease from the old server is still good so this client has not yet requested a renewal on the lease, this is important because the DNS server for the client has changed – if we were to demote the 2003 server at this time the clients would have issues resolving and authenticating
- On the client run IPConfig /Release
- On the Client run IPconfig /renew
- Then Validate that the 2012 R2 server handed the clients IP Address
- Check current settings, notice that the lease from the old server is still good so this client has not yet requested a renewal on the lease, this is important because the DNS server for the client has changed – if we were to demote the 2003 server at this time the clients would have issues resolving and authenticating
- Once all FSMO’s, DHCP to all clients have been updated shut down the old server for a few days to make sure nothing was missed and that clients are able to authenticate to Active Directory, Get to the internet, etc
-
Last step is to demote the 2003 server
- Run DCPromo on 2003, Click Next
- Do not select this is the last domain controller in the domain, Click Next
- Type a new Local Administrator Password, Click Next
- Click Next on the Summary Screen
- Active Directory will then be removed, and the server will be rebooted
- Run DCPromo on 2003, Click Next
In this blog post , I am going to list the steps involved in transition from a Windows 2003 R2 Small Business Server Domain Controller to a Standard Windows 2012 Domain Controller.
The server involed in this process are:
Windows 2003 Small Business: adc-sbs
Windows 2012 Standard: adc-2012.
First of all, I’ve installed the Windows 2012 Server using a static IP address and set the preferred DNS server “pointing” to adc-sbs ip address. Next we have totally updated both Servers with all the latest Windows, and verified that the date/time is correct.
Backup
First of all: backup !
We always need to ensure that we take a complete backup along with System State Backup of the SBS Server if something goes wrong.
Check AD
To ensure a seamless transition we need to perform an health check of AD in Windows SBS 2003 using tools like dcdiag.exe (contained in Windows 2003 Support Tools) and Microsoft Windows Small Business Server 2003 Best Practices Analyzer (see linkografia).
Uninstall UnUsed Software
In the new Windows 2012 environment I won’t use Exchange, WSUS and other stuff: for this reason, and also to avoid problems, my advice is to uninstall any software or service that is not useful in the Windows 2003 SBS. The procedure I usually follow in such cases is to make to make a list of software to uninstall: after that I uninstall of the first one, wait a few days to see that there are no problems between the users and other installed services, and then uninstall the later program in the list.
Exchange is often very difficult to remove, but we have to uninstall fully, to make sure AD is cleaned up during the migration process.
Remove Legacy GPO
To simplify the transition to the new server, we need to minimize the number of GPOs involved.
Also the Group Policy objects are updated a lot for Windows 2012: these are not simply a superset of the Windows SBS 2003 GPOs, but some of then can be incompatible.
For this reason it is best to just leave the “main” GPOs, deleting all the others: at the end of the migration process we can recreate in the new environment the GPOs taking advantage of the new capabilities.
- Open Server Management: in the navigation pane, click Advanced Management, click Group Policy Management, and then click Forest: <Your Domain Name>.
- Click Domains, click <YourDomainName>, and then click Group Policy Objects.
- Right-click Small Business Server Auditing Policy, click Delete, and then click OK.
- Repeat the step to delete all of the others GPOs: recommend leaving only Default Domain Controllers Policy and Default Domain Policy.
- At the end click WMI Filters, and delete all the items (PostSP2, PreSP2, etc)
Remove Logon Settings
Always to simplify the transition to the new server, and to avoid any issue in this process, we will remove any legacy an unused log script.
Att.: Windows SBS 2003 uses logon scripts to install software and for other tasks. In Windows 2012 these task can be replaced with a combination of GPOs and logon scripts, that work more efficiently.
- Click Start, and then click Run: type \\localhost\sysvol\<DomainName>.local\scripts, and then press ENTER.
- Delete or rename SBS_LOGIN_SCRIPT.bat and check the other cmd or bat files.
After that verify that all users’ profiles are updated to not use a logon script: to verify user profiles follow the next.
- Click Start, click Administrative Tools, and then click Active Directory Users and Computers.
- In the navigation pane, expand <DomainName>, expand My Business, expand Users, and then expand SBSUsers.
- Ctrl-click to select all user accounts, right-click the highlighted user accounts, and then click Properties.
- On the Profile tab, verify that the logon script check box is blank.
Set the minimum functional level
The minimum functional level must be at least Windows Server 2003: please control that the Domain functional level is set to Windows Server 2003, in AD Users and Computers right click the “Domain Name”. Also control that the Forest functional level is set to Windows Server 2003, in AD Domains and Trusts right click “Active Directory Domains and Trusts”.
Join Windows 2012 to the domain
To join a domain, just click the current domain or workgroup name in Server Manager and .
A reboot will be required.
Install Active Directory Domain Services in Windows 2012
1) Start the Server Manager and choose “Add roles and features”, in “Before you begin” click next, in the “Installation Type” use “Role-based or feature-based installation” and click Next.
2) Choose adc-2012 and click Next.
3) Now check the Active Directory Domain Services and in the upcoming window click the “Add features” button.
4) Leave selected Group policy management and then Click Next and then choose “Restart the destination automatically if required” and press Install .
Promote the server to be a domain controller
1) After installing the Active Directory Domain Services feature on your server, it is possible promote it to be a domain controller. If you have just finished the feature installation, the AD DS Configuration Wizard begins automatically: however, if the feature installation has already been closed, you can start the Active Directory Domain Services Configuration Window by clicking the Tasks icon along the top of Server Manager and click “Promote this server to a domain controller”.
2) Supply the credentials for the operation: an administrative user in the domain.
3) Check “Add a domain controller to an existing domain”
4) Choose Domain Name System (DNS) server and Global Catalog (GC) and type the Directory Services Restore Mode password and then click Next.
5) Now you will be prompted with the warning in the next.
A delegation for this DNS server cannot be created because the authoritative parent zone cannot be found or it does not run Windows DNS server. If you are integrating with an existing DNS infrastructure, you should manually create a delegation to this DNS server in the parent zone to ensure reliable name resolution from outside the domain “test.local”. Otherwise, no action is required.
You do not need to be concerned about this warning message: click Next.
6) Choose Next and either use the default. Leave IFM (Install from media) Unchecked and click Next.
7) Location of the AD DS database, Log Files and Sysvol: here you can leave the default and click Next.
Click Next and then Next: here information about forest, schema and domain update is shown. Click Next and a prerequisite checks will be done.
9) Review the Check (usually all the warning can be ignored) and click Install.
A reboot is required and it happens automatically by default: at the end the Windows 2012 will be a DC. Pls check the event viewer for any possible problems.
Transfer FSMO roles to Windows 2012 server
Att.: After you move the FSMO roles away from Windows 2003 SBS you have 21 days grace period to keep the server box running. After the completion of 21st day, the server simply will stop to work: so it’s recommended to perform these final steps before this period end.
To transfer all 5 of the FSMO roles simply run the following command in PowerShell in Power Shell on Windows 2012 server:
Move-ADDirectoryServerOperationMasterRole -Identity “adc-2012” –OperationMasterRole PDCEmulator,RIDMaster,InfrastructureMaster,SchemaMaster,DomainNamingMaster
Once you transfer the FSMO roles to the new DC, adc-sbs will start to complain and shutdown itself down on regular intervals “by design” (pls see in linkografia Extend 21 day limit).
To check if adc-2012 hold all the AD roles use the next power shell commands.
Enter-PSSession adc-2012 Import-Module activedirectory Get-ADForest smallbusiness.local Get-ADDomain smallbusiness.local
Demote Windows 2003 SBS
Now it is possible demote the SBS server so it is no longer a domain controller and remove from network , reformat and use the hardware for any other purpose
Start -> Run -> DcPromo
Att.: Do no select the flag “Delete the domain because this server is the last domain controller in the domain” otherwise all will be deleted !
Final checks
In the windows 2012 server pls verify that in DNS server in Windows 2012 do not remain any reference to the old Windows 2008 server.
DNS zone smallbusiness.local → Properties → Name Server
You have to do the same check in the network connection: WINS, DNS, etc.
Least but not least the time server: in fact it is required to reconfigure the time service on the old and new PDCEmulator, so a recommended external time source is used.
The following command will force the time service in the new Windows 2012 server to do a syncronization, which will be reported in the System Event Log (pls check if all works fine) and set itself like a reliable time source in the AD smallbusiness.local. In the command line in the windows 2012 server the the following.
w32tm /config /syncfromflags:manual /manualpeerlist:pool.ntp.org /reliable:yes w32tm /config /update net stop w32time net start w32time
That’s all……approximately….
Linkografia
Microsoft Windows Small Business Server 2003 Best Practices Analyzer
http://www.microsoft.com/en-us/download/details.aspx?id=5334
Windows 2003 SBS: Extend 21 day limit
http://blog.thesysadmins.co.uk/sbs-2003-to-sbs-2011-migration-extend-21-day-limit.html
Windows Server 2003 support has ended on July 14, 2015. If you still have 2003 servers in your environment, now is the time to get rid of them – migrating to newer 2008, 2012, 2016 or Server 2019.
Since 2003 servers are quite old, and since there is no direct upgrade path from Server 2003 to Server 2019, 2016 or 2012, the recommended way to eliminate Server 2003 is to transfer to new hardware – not an in-place upgrade.
In this article, we’ll learn how to perform a Windows Server Migration for a typical application server, while making sure no applications or files are lost in the process.
Using this tutorial generally allows to complete a server migration in less than 24 hours (although complicated cases may require more time).
The tutorial is below, and before that – a video tutorial and a few common questions about Windows Server 2003 EOL and migration.
The tool used in this this tutorial – Zinstall WinServ – is also available from IBM Services, as part of their full service package for large scale deployments. Contact your IBM account team in your region for more information.
Video tutorial – automatic server migration
Q: Can I transfer the applications I am currently running on Windows Server 2003 to a new Server 2012 / 2016 / 2019?
A: Yes. Using a product such as WinServ, you can automatically transfer all applications, profiles, shares and data to a replacement server 2012 / 2016 / 2019. Note that a small part of legacy 2003 applications may not be natively compatible with newer servers. For those, the WinServ package can perform a virtualized migration.
Q: What if my applications are no longer supported, or I no longer have the installation discs?
A: Even if you have no way to install your applications on the new server, you can still transfer them from the old one – using a dedicated migration tool, such as the WinServ package discussed in this tutorial. WinServ is application-generic, and here is a partial list of what it migrates:
- MS SQL
- MySQL
- SAP (including SAP Business One)
- Oracle
- Sybase
- DB2
- Java Application Server
- Crystal Reports
- Avaya
- PeopleSoft
- JD Edwards Enterprise One (JDE E1)
- Citrix
- Apache (Windows only)
- WebSphere
- Microsoft Dynamics
Q: What happens if I just stay with Windows Server 2003 after July 14, 2015?
A: It won’t explode. However, Microsoft will no longer provide support, and will charge up to $600 per incident if you do ask them for assistance.
Q: What are the benefits of transferring away from Windows Server 2003?
A: A new server is incomparably more secure and more powerful than the old one you’ve had running for many years. It can utilize more than 4GB of memory, which means that a much higher load can be put on a single physical machine, including virtualized server. Along with the security aspect of up-to-date OS, overall performance is expected to be much better.
How to migrate from Windows Server 2003 to Windows Server 2008 / 2012 / 2016 / 2019
This tutorial is divided into two primary sections, representing the two types of migration tasks on any server: 1) Applications, profiles, shares and data migration and 2) Server Roles migration.
The first part can be automated using dedicated server migration tools such as WinServ, as we will show in the tutorial. The second part requires manual work, for which guidance will be provided – or hiring a service that performs that.
For an application server, you only need the first part.
Before the migration:
-
- Audit your servers: Make sure you know what the server is responsible for. You need to make two lists:
- Which roles is the server running (is it a DC? Does it run DNS/DHCP? IIS? Print?). For roles migration, the only way is a manual migration, or a Server Migration service. In this tutorial, we’ll focus on automatic migration of server applications.
- Which applications are running on the server? (Oracle? SQL? CRM? 3rd party applications?). These can be migrated automatically using an appropriate tool, which will be covered further in this tutorial.
- Audit your servers: Make sure you know what the server is responsible for. You need to make two lists:
Tip: If your organization is not using a centralized management tool (e.g. Microsoft SCCM) to monitor your servers, you can download the free Microsoft Assessment and Planning (MAP) Toolkit here. You can also use Zinstall’s free server diagnostic at this link. It allows for quick check-up of server’s entire software and hardware list.
- Schedule your migration time slot: Migrations take time, and during that time, your users may be affected to some extent. If possible, try and schedule the actual migration to be performed after hours or during a weekend. Note that you don’t actually have to stay there yourself at that time: application migration can be performed remotely or launched in advance in unattended mode.
- Verify your backups are up to date, and are actually restorable: Any major upgrade may go wrong, and without a valid up-to-date backup, you risk losing everything you’ve had on the server. Make sure to verify that the backup you have is not damaged and ready to be restored if needed!
- Decide on replacement type: Once you have decided to replace a server, you have several options regarding what the replacement will be. It may be a physical Windows 2012 / 2016 / 2019 server, a virtual server running on premise, or even a Cloud-based server running off premise. WinServ supports any of those transfers, so migration difficulty does not vary significantly with your choice.
Applications, profiles, shares and data migration
Here is the process for performing a migration for a source Windows 2003 Application Server to a target Server 2012 / 2016 / 2019:
- Fully update and patch the target server.
- Add the target server to the domain.
- Run WinServ (or a similar tool) on the source (2003) server and on the target (2012, 2016 or 2019) server.
- At this stage, you can either transfer directly over the network, or perform an indirect migration – capturing the source server to a container on network storage / cloud storage, and then deploying from that container on the new server.
- Before you start the transfer, you also have an option to pick and choose applications and data that you want to transfer. Or, just run the transfer to migrate everything.
- Press “Go” on the target server in order to initiate the transfer.
Depending on the amount of transferred data and applications, the actual transfer may take several hours to complete. You will see progress indication throughout the process.
Server Roles migration
This part of the migration is done manually, and multiple tutorials exist that may help. We recommend John Savill’s excellent guide: Winding Down Windows Server 2003 in Your Organization. Information below is based on the article above.
- IIS migration: If all you have running on IIS 6 are basic HTML pages or Active Server Pages (ASP), you can copy the content to the IIS version running on Server 2012 or Server 2012 R2, then update the DNS records to point to the new IIS server. However, organizations typically have more complex configurations. The good news is that you can use a migration toolkit named Web Deploy 3.6. If you need to migrate websites to Microsoft Azure Web apps, see Azure Web App Migration Assistant.
- DC and AD migration: Providing you have followed best practices, your domain controllers (DCs) don’t run any other software, which means the existing domain and forest will be prepared for Server 2012 or Server 2012 R2. In this case, you need to create new DCs running Server 2012 or Server 2012 R2, migrate the Flexible Single-Master Operation (FSMO) roles, migrate any certificates or other items, then decommission the Server 2003 DCs. To introduce Server 2012 DCs, the forest (and therefore the domains) must be Windows Server 2003 mode. For detailed guidance on migrating DCs, see Upgrade Domain Controllers to Windows Server 2012 R2 and Windows Server 2012.
- DHCP migration: DHCP scopes provide the IP addresses given to clients, along with their IP configuration (e.g., gateway, DNS server). To migrate DHCP scopes, the best option is to export the scopes from the Server 2003 instance, then import them to the Server 2012 or Server 2012 R2 instance. Full details on this approach are available in the TechNet Networking Blog post “Steps to move a DHCP database from a Windows Server 2003 or 2008 to another Windows Server 2008 machine.” If there is any delay in the DHCP scope export and import and a risk of IP address reuse, you can configure the DHCP server to check if an IP address is being used before it’s allocated by enabling address conflict detection.
- DNS migration: If you’re hosting DNS on Windows, you’re likely integrating it with AD and your DNS servers are DCs. Therefore, when you migrate AD, the DNS configuration will move as well. It’s important to remember to migrate any DNS server configurations, such as forwarding. If the DNS servers will be hosted on new IP addresses, you need to make sure that you update any static IP configurations and all DHCP configurations. To avoid this time-consuming task, most organizations will change the IP addresses of the new servers to that of the old servers once the old servers are retired.
- Print services: Like file services, printer configurations and shares must be migrated from the source server to the target server. In addition, you’ll need new printer drivers that are 64-bit and compatible with Server 2012 or Server 2012 R2 as well as with modern clients. Microsoft has a print migration wizard and command-line tool you can use for migrating printer services. You can download these tools from the Migrate Print and Document Services to Windows Server 2012 web page.
- Exchange migration: Upgrade from Exchange 2007 to Exchange 2013
- SQL server migration: See Supported Version and Edition Upgrades
Dealing with incompatible applications:
Some legacy 3rd party applications running on Windows Server 2003 may be incompatible with Windows Server 2008 or Windows Server 2012. Such applications are generally legacy DOS, 16-bit or 32-bit only software, which has not been updated for newer OS versions. It is strongly recommended to eliminate these applications from the production environment as soon as possible.
If these applications cannot be eliminated immediately, and are mission-critical for continued operation of the organization, the recommended option to preserve them operational is to perform a virtualized migration of those applications, into a virtual Server 2003 instance running on newer replacement server. Then, continue to take the steps required to phase those applications out and stop running the virtualized 2003 instances.
Such P2V (physical to virtual) migration should be done using WinServ as well.
After the migration:
Once the migration process is complete, it is time to verify the results.
- You may need to adjust your domain’s DNS to point to the new server where needed. For example, changing the CRM-SERVER DNS entry to the new server’s address.
- Same goes for login scripts and GPO policy.
- Launch every application and console you use, and verify they load correctly.
- Using a client workstation, verify that clients can access the migrated server correctly and their applications run without issues.
Congratulations! Your application server migration is now complete.
Ready to migrate your Windows 2003 servers to 2016/2019?
Get Zinstall WinServ here
You can also contact us for assistance, volume licensing, and help in setting up a POC.
Для тех, кто все еще работает с Windows Server 2003: оцениваем ресурсы и составляем план переноса
Как известно, многие компании не перешли с Windows Server 2003 даже после наступления даты окончания официальной поддержки поставщика. Что же такое важное заставляет их продолжать работать с более чем 14-летней устаревшей серверной операционной системой? А ответ простой — потому что она все еще нужна. Процессы миграции могут иметь негативные последствия и сложны сами по себе, и просто сам факт того, что появилась новая версия чего-либо, не вызывает у пользователей желания переходить к ней. Если сервер делает то, что от него требуется, совершенно не обязательно переход на новую версию операционной системы позволит ему выполнять свои обязанности еще лучше. Скорее всего, у вас просто появится больше возможностей или вы сможете делать что-то, что до этого не могли. Чаще всего инструмент выбирают такой, который будет делать то, что от него требуется. И даже когда появляется усовершенствованный инструмент, на деле нет особого смысла отказываться от первоначального.
К тому же, если разобраться, то не все серверы с Windows Server 2003 устанавливались в один день именно 14 лет назад, поэтому не все они такие уж старые с точки зрения аппаратной платформы. Например, хотя версия Windows Server 2012 R2 существует уже более 4 лет, несколько месяцев назад я вынужден был установить версию Windows Server 2008 R2, поскольку она требовалась для клиентского приложения, которое еще не поддерживалось производителем на версии 2012. Поэтому некоторые серверы с 2003 на самом деле имеют возраст 6-8 лет. Я никогда не мог убедить клиентов установить операционную систему просто из-за ее новых функций, они разворачивали ее, только когда наступал подходящий момент поменять оборудование, а для малого бизнеса это и наиболее экономичный путь.
Обновление и замена серверов
Как показывают данные о числе серверов с работающей по сей день версией Server 2003, достаточное количество компаний придерживаются при развертывании серверов принципа «работает — не трогай». Другой подход подразумевает развертывание новой версии как можно быстрее и устранение возникающих проблем уже в процессе эксплуатации. Первый подход в большей степени свойственен тем, кого называют системными администраторами, а второй в значительной мере характеризует позицию разработчиков программ.
Можно привести грубую метафору для описания разницы в подходах: системные администраторы хотят построить мост и поддерживать его в рабочем состоянии десятилетия, а разработчики используют мост только до тех пор, пока не появится новая версия моста. Подход системных администраторов не годится для компании, которая живет за счет продаж лицензий на новые версии серверной операционной системы. Автомобильные компании не приходят в восторг, когда люди покупают автомобиль и надеются проездить на нем не менее 20 лет.
Как полагают некоторые, снижение внимания Microsoft к нуждам системным администраторов стало наблюдаться после анализа компанией того факта, что многие сотрудники компаний, отвечающие за работу серверов, склонны тратить деньги на новые серверные продукты как можно реже. Разработчики же, в противоположность им, имеют репутацию любителей новинок и с большим энтузиазмом относятся к проведению обновлений.
Когда в 2020 году для Windows Server 2008 и 2008 R2 завершится срок поддержки, мы все снова окажемся на знакомом перекрестке. Будет огромное число компаний, которые довольны работой имеющегося продукта, пусть ему уже на тот момент будет более десяти лет. То есть тех, кто рад продолжать использовать мост, пока он остается надежным и безопасным, пусть даже его дизайн отстает от новых веяний на пару поколений
Слухи о смерти Windows Server 2003 сильно преувеличены
Неудобная правда заключается в том, что огромное число серверов, на которых запущен Windows Server, все еще жужжат в серверных комнатах и центрах обработки данных, даже спустя месяцы после окончания поддержки их операционной системы. Часто на конференциях я прошу слушателей поднять руки, у кого в компании есть хоть один производственный сервер с Windows Server 2003, и иногда до трети аудитории выполняют мою просьбу. Пока я писал статью об окончании поддержки Windows Server 2003, мне часто задавали вопросы на данную тему, и я понял, что для многих пользователей эта операционная система все еще предмет ежедневных забот.
Общаясь с пользователями на конференциях, я разрешил многие свои сомнения. Прежде всего, большинство системных администраторов уже давно желают отказаться от использования Windows Server 2003, но руководители компаний не считают эту проблему приоритетной. До тех пор пока операционная система сама по себе не перестанет работать, никакие миграции не будут осуществляться, и начнутся они, только когда компания будет готова, но никак не с наступлением срока окончания поддержки, воспринимаемого как произвольно назначенный.
Отсутствие плана перехода с Server 2003
Многие компании, все еще использующие Windows Server 2003, по-прежнему не имеют твердых планов относительно сроков и способов перехода на другую версию операционной системы.
Планы отсутствуют, потому что компании не знают, когда будет совершен переход от Server 2003. Они не знают, когда произойдет миграция, потому что серверы с этой операционной системой по-прежнему функционируют, и поскольку это положение сохранится в обозримом будущем, руководство хочет или нуждается в том, чтобы ИТ-специалисты занимались решением других задач.
Многие компании применяют подход, известный как «системное администрирование проблем», то есть системное администрирование заключается исключительно в реагировании на события, без попыток упреждающих действий. Вы решаете задачи, влияющие на производственную деятельность сегодня, но не те, которые могут определять будущее.
Многие компании, для которых ИТ не являются основным приоритетом, относятся к серверной инфраструктуре так же, как к сантехнике, кондиционерам и другому оборудованию, необходимому, но не играющему ключевой роли в бизнесе. Руководители, ответственные за принятие решений, делят затраты на ИТ на необходимые и необязательные. Когда бюджет ограничен, замена исправно функционирующего продукта на другой продукт, который будет выполнять ту же задачу, рассматривается как роскошь, а не как необходимость.
Windows Server 2003 в 2017 году
Недавно мне довелось участвовать в одном мероприятии. На каждой встрече я проводил опрос аудитории, чтобы выяснить, многие ли все еще используют Server 2003 в своей компании. Каждый раз 30-40% присутствующих поднимали руки.
Следом я задавал вопрос, действительно ли кому-то нравится работать с Server 2003. Ни одной поднятой руки. Затем я спрашивал, существуют ли факторы вне контроля ИТ-подразделений, препятствующие миграции. И вновь 30-40% присутствующих поднимали руки. Далее я интересовался, сколько компаний имели соглашения о технической поддержке Server 2003. К моему удивлению, очень немногие пользователи, работающие с Server 2003, позаботились о поддержке операционной системы.
Так что нечего удивляться, что и в этом году некоторые компании будут работать с Server 2003. С позиций руководства Windows Server 2003 «просто работает». Все текущие поставщики средств виртуализации поддерживают Windows Server 2003, то есть, в отличие от предшествующих операционных систем, она не выйдет из употребления из-за износа оборудования или отсутствия драйверов устройств. Возможно, на каком-то этапе в будущем продукты виртуализации перестанут функционировать с Server 2003, но, учитывая, что Hyper-V в Server 2012 R2 позволяет запускать виртуальные машины Server 2003, а Server 2012 R2 будет поддерживаться компанией Microsoft до 2023 года, я не уверен, что количество экземпляров Server 2003 значительно сократится в обозримом будущем.
Думаю, если мне удастся спросить посетителей той же конференции в этом году, имеется ли в их компании хотя бы один экземпляр Server 2003, то от 15 до 20% присутствующих ответят утвердительно. Вероятно, пройдет несколько лет, прежде чем число компьютеров с Server 2003 станет настолько малым, что его можно будет игнорировать как статистическую погрешность.
Платная поддержка Windows Server 2003
Компании, в которых все еще работают серверы с Windows Server 2003, могут рассчитывать на платную поддержку от Microsoft и получать обновления для операционной системы. Но нужно иметь в виду, что если вы заключите такой контракт на поддержку и получите нужные обновления, то не сможете использовать для их развертывания службу Windows Update. Вам придется задействовать другие средства для обновления систем с Windows Server 2003. Что-то подобное было реализовано военно-морским флотом США, когда Microsoft было уплачено 9 млн. долл., и компания обеспечила поддержку для устаревшей Windows XP.
Сколько будет стоить такая особая поддержка для вашей компании? Это зависит от многих факторов. Я полагаю, в данном случае нет установленных расценок. Вам придется вести переговоры с представителями Microsoft, а они прежде всего попробуют уговорить вас прекратить использование Windows Server 2003, так что, скорее всего, эта поддержка вам «влетит в копеечку». Как я уже отмечал выше, на одной конференции из нескольких сотен слушателей 30-40% подтвердили, что все еще применяют Windows Server 2003 в своих сетях. Но в ответ на вопрос, кто из использующих эту версию операционной системы имеет контракт на ее поддержку, руки подняли всего несколько человек. Судя по всему, большинство из тех, кто еще работает с системами на базе Windows Server 2003, делает это без поддержки, что может иметь для них последствия в виде, например, несоответствия отраслевым требованиям.
План необходим
Как бы сильно вы ни хотели избавиться от старых систем, просто сказать «пропадите вы пропадом» недостаточно, нужен реальный план по выводу серверов Windows Server 2003 из рабочей среды, и к его разработке следует приступить как можно скорее. Прежде всего, надо определиться с тем, что реально требуется сделать. Тот факт, что такие серверы до сих пор остались в вашем центре обработки данных, говорит о том, что избавиться от них не так-то просто. И процесс извлечения Windows Server 2003 из рабочей среды подобен финальной схватке с самым сильным противником на самом последнем уровне сложности в компьютерной игре. Чтобы одолеть такого мощного противника и получить все причитающиеся победителю награды, нужно иметь стратегию ведения поединка.
Есть и другая причина, почему вам нужен план. Если вы хотите заключить пользовательское соглашение о поддержке с компанией Microsoft, вам понадобится подготовить план миграции с Windows Server 2003, в случае же его отсутствия Microsoft не будет заключать договор с вашей компанией.
В план нужно включить следующие действия:
- оценка ресурсов, которые необходимо перенести в новую среду;
- способ переноса ресурсов, а также выбор платформы, на которую будет выполняться перенос;
- период времени, за который нужно выполнить миграцию.
Если же вы не знаете, какие ресурсы необходимо перенести, не выбрали способ переноса и у вас нет определенности со сроком выполнения миграции, придется признать, что план у вас отсутствует.
Чем скорее, тем лучше
Все, кто работает с системами на базе Windows Server 2003, должны в какой-то момент все же осознать, что эксплуатация серверов с операционной системой Windows Server 2003 не может продолжаться вечно. Когда-то все эти серверы придется «отправить на пенсию», и чем скорее, тем лучше.
Из той информации, что мне удалось собрать, я могу заключить, что администраторы серверов тех компаний, где все еще используется Windows Server 2003, с радостью бы от них избавились, но руководство не желает тратить ресурсы на решение этой проблемы. Другие администраторы, когда я спрашивал их, говорили, что их руководство придерживается позиции, что пока системы с Windows Server 2003 работают, нет необходимости в их замене, до тех пор пока не останется другого пути.
Есть еще мнение, что изменился и сам процесс функционирования и соответственно износа серверов. И проблемой для многих компаний является то, что износ серверов с Windows Server 2003 происходит совершенно по-другому, если сравнивать с серверами версии Windows 2000 или даже Windows NT 4. Большинство серверов с версией Windows NT4 Server были развернуты как физические серверы. А большая часть серверов с работающей версией Windows Server 2003 сегодня запущены как виртуальные машины. Нет нужды говорить, что виртуальные машины не страдают от эффекта физического старения аппаратного обеспечения в той же мере, что физические серверы с развернутой на них версией Windows Server 2003. И тем ИТ-специалистам, которые ждут момента, когда сервер сломается, чтобы только потом заменить его, придется ждать довольно долго.
Рассмотрим альтернативы
Для большинства специалистов отказ от Windows Server 2003 означает миграцию на новую версию Windows Server. Но бывает, что вместо обновления до Windows Server 2012 R2 или 2016 в некоторых компаниях рассматривают и другие варианты, например новую операционную систему или автономное аппаратное устройство. Недаром ведь Microsoft «заигрывает» с другими операционными системами в силу необходимости учитывать гетерогенные архитектуры. И сегодня намного легче, чем раньше, интегрировать решения другого производителя, например на базе Linux, или фирменные аппаратные устройства в сети Microsoft.
Но прежде чем внедрять альтернативные решения, ИТ-специалистам компании следует четко понимать, почему именно их компания избавляется от Windows Server 2003. Только после получения ясного представления о причинах отказа от Windows Server 2003 можно определить, будут ли существующие вне экосистемы продуктов Microsoft альтернативные решения соответствовать требованиям компании. Большой ошибкой многих компаний, которые переходят на альтернативные решения, является очень приблизительное понимание того, что именно делает продукт, которые они использовали прежде. Они переходят на альтернативное решение и неожиданно узнают, что некоторые имевшиеся ранее и неучтенные при переходе критически важные функции стали недоступны, поскольку в альтернативном решении они не реализуются.
Другим недостатком замены операционных систем Microsoft альтернативными решениями является необходимость для системных администраторов компании изучать новую технологию, погружаясь в нее хотя бы для облегчения предстоящего перехода. У сторонних разработчиков есть инструменты для оказания помощи в осуществлении миграции, будь то перенос корпоративного приложения на другую серверную систему во внутренней сети или реализация его с помощью «облачных» служб.
Давайте рассмотрим для примера варианты переноса нескольких серверов Windows Server 2003 на Linux, а затем миграцию существующего файлового сервера на сервер Samba.
Замена Windows Server 2003 на Linux
В тех компаниях, где на серверы с операционной системой Windows Server 2003 возложен ограниченный круг задач и в которых есть подготовленные нужным образом системные администраторы, имеет смысл запустить некоторые серверы с вариантами операционной системы Linux, а не новой версии Windows Server. Например, вместо миграции сервера DHCP на базе Windows Server 200 на новую версию 2016 реализовать решение с поддержкой службы DHCP сервером Linux.
Идея замены сервера Microsoft на какою-либо разновидность Linux отвергалась с порога еще лет десять назад, однако обращало на себя внимание то, что многие инструменты для управления несколькими серверами, вроде Chef и Puppet, были способны управлять одновременно как серверами Linux, так и Windows. Да и сами разработчики Microsoft работают над возможностями PowerShell по взаимодействию с Linux, так что можно выдвинуть предположение, что когда-то в обозримом будущем будет возможно использовать компонент PowerShell под названием Desired State Configuration для настройки работающих серверов Linux таким же образом, как это делается для настройки операционной системы Windows Server.
Ключом к успеху реализации варианта по замене служб, хостируемых на серверах с операционными системами Microsoft, на службы, хостируемые на серверах с операционной системой Linux, является способность имеющейся команды системных администраторов управлять серверами на базе Linux. Если такие обученные администраторы в ИТ-подразделении есть, то данный вариант перехода имеет смысл. Если же дело обстоит не так, то для компании более уместным будет переход к Windows Server 2012 R2 или 2016.
Samba вместо файлового сервера
Чаще всего сервер с работающей на нем операционной системой Windows Server 2003 используется как файловый сервер. Если ваша компания не заинтересована в обновлении до последней версии Windows Server, то можно рассмотреть возможность реализации службы общего доступа к файлам на базе сервера Samba на Linux. У производителя есть отличная документация по всем этапам, необходимым для добавления файлового сервера Samba на Linux в существующий домен. Кроме того, большинство компаний не тратят много времени на настройку расширенных свойств и функций файловых серверов. Если компании требуются по большей части самые простые возможности файлового сервера, то вариант с заменой файлового сервера на Windows Server 2003 сервером Samba на Linux вполне подойдет. К тому же Microsoft участвует в проекте по разработке программного обеспечения с открытым кодом для Samba, что, возможно, даст ей новые пути взаимодействия с другими разработчиками, и я не удивлюсь, если интеграция Samba на Linux с сетями на базе Windows со временем станет еще проще.
С помощью контроллеров домена на базе Samba возможно также создание собственного домена. Насколько это практично, зависит от тех функций службы каталогов Active Directory, которые применяются в вашей компании. Samba реализует только самые базовые из них, и если в компании используются расширенные возможности Active Directory, то системным администраторам придется поддерживать в сети еще и контроллер домена на базе Windows Server.
Нужен ли компании контроллер домена?
При рассмотрении вопроса перехода от Windows Server 2003 к новой версии ИТ-подразделения следует решить вопрос о том, нужны ли компании локальные контроллеры домена. В прошлом небольшим предприятиям контроллер домена нужен был для аутентификации пользователей с их учетными записями для получения доступа к файловому серверу, почтовым ящикам на сервере Exchange Server и хранящимся на сервере ресурсам SharePoint. Сегодня большинство этих ресурсов доступны в «облаке», например в Office 365, и многим небольшим компаниям больше не требуется локальное решение для доступа к электронной почте, сайтам SharePoint, да и Exchange Server уже локально в таких компаниях практически нигде не хостируется.
Многие компании при рассмотрении вопроса миграции решают перенести все службы в «облако». Это особенно важно для тех компаний, которые развернули в свое время какую-либо версию набора серверных приложений Small Business Server. Так как новой версии для Small Business Server просто нет, то большинство решает перейти на Office 365 и использовать общедоступные версии SharePoint и Exchange.
Переход на использование общедоступных сетевых служб взамен служб в локальной сети имеет смысл, если учесть, что большинство малых предприятий предоставляют своим сотрудникам переносные компьютеры, а не традиционные настольные. Если персонал компании чаще использует компьютеры вне локальной сети, то модель с процедурой регистрации в домене, которая пришла из тех времен, когда большинство компьютеров стояло на столах в офисе, становится не очень удобной. Так что нужно теперь учитывать и это.
А нужна ли централизованная регистрация в домене?
Для определения того, нужно ли отказаться совсем от контроллера домена Windows Server 2003 или все же обновить его, следует ответить на вопрос: а нужна ли компании централизованная регистрация пользователей на контроллере домена, расположенном в ее локальной сети? Ответ на этот вопрос зависит во многом от модели доступа к ресурсам в компании. Централизованная регистрация необходима при предоставлении пользователям доступа к локальным ресурсам компании, например к Exchange Server, файловому серверу или SharePoint. Если компания планирует или уже начала перенос таких ресурсов в «облако» либо перенесла некоторые ресурсы в «облако», доводы в пользу локального контроллера домена становятся намного слабее. Тем более в том случае, если компания практически не использует групповые политики.
Попробую пояснить. Одной из не слишком заметных функций Windows 10 является возможность выполнения объединения доменов с «облачной» службой каталогов, или Azure Active Directory Domain Join. Вместо регистрации в системе Windows 10 с традиционной доменной учетной записью или с персональной учетной записью Microsoft, например с учетной записью на outlook.com, возможно выполнение регистрации с учетной записью Azure Active Directory, например с одной из учетных записей для Office 365. То есть вместо отдельной регистрации в Office 365 регистрация происходит в тот момент, когда пользователь регистрируется на своем компьютере. После этого доступ к Exchange Online и OneDrive for Business происходит автоматически. Учтите также, что Microsoft намеревается реализовать возможность управления устройствами в Office 365.
Если компания имеет подписку на Office 365 и развертывает системы Windows 10, то для нее имеет смысл избавиться от локальных контроллеров домена. Вне зависимости от того, есть ли локальные ресурсы, доступом к которым вы хотите управлять с помощью доменной учетной записи. Если же компания имеет солидную инфраструктуру файловых серверов, то для нее избавление от контроллеров домена не имеет смысла. Но если вы долго думаете над тем, какие локальные ресурсы требуют доменной учетной записи, возможно, вам следует рассмотреть вопрос об исключении локальной службы каталогов из уравнения.
Избавление от централизованной локальной регистрации скорее имеет смысл для небольших компаний, чем для крупных, имеющих распределенную сетевую инфраструктуру. В таких сетях всегда найдется место локальной службе каталогов Active Directory, эта служба всегда будет заботой для крупных и средних компаний, но маленькие компании в кои-то веки смогут выключить этот надоевший ящик, который жужжит в комнате отдыха или под столом секретаря.
Azure AD — не «облачный» контроллер
По поводу того, что может и чего не может служба каталогов Azure AD, существует недопонимание, в том числе по поводу ее способности выступать в роли контроллера домена, расположенного в «облаке». В настоящее время она не может этого делать. И хотя вы можете подсоединять компьютеры с Windows 10 к Azure AD, это не делает ее полноценной заменой контролеру домена. Самое очевидное отличие состоит в том, что Azure AD не поддерживает объекты групповой политики, GPO. Другое отличие в том, что в Azure AD хранится только подмножество всех атрибутов, которые хранятся в локальной среде AD. При подсоединении локальной службы каталогов AD к Azure AD только часть ее атрибутов реплицируется в «облако». Вполне логично предположить, что число атрибутов, доступных в Azure AD, будет расти, но столь же резонно заявить, что вряд ли когда-либо будет достигнуто полное соответствие между атрибутами, доступными в Azure AD, и атрибутами, имеющимися в локальной службе AD.
Большинство компаний не формируют отдельный экземпляр Azure AD для своих нужд. Хотя это и можно реализовать, по большей части служба Azure AD используется как внутренняя при развертывании Office 365 и Microsoft Intune. Наличие такого экземпляра имеет смысл при подключении компьютеров компании к Azure AD при развертывании Office 365 в целях упрощения интеграции между Windows 10, Office 365 и, возможно, Microsoft Intune. Сегодня сложно сказать, получит ли Azure AD функции типа GPO, скорее всего, нечто подобное параметрам управления, которые реализуются средствами локальной групповой политики, будет реплицироваться через подобные Intune службы.
Незаметный ИТ-отдел
Как уже упоминалось, я не встречал ИТ-специалиста, довольного тем, что в его сетевой среде все еще используется Windows Server 2003. Но руководство не выделяет ресурсов для выполнения миграции. ИТ-специалисты ясно понимают причины, почему им необходимо отказаться от Windows Server 2003, и осознают, что в работе со столь старой и неподдерживаемой производителем операционной системой ничего хорошего нет. Они работают с ней не потому, что настолько привержены Windows Server 2003, а потому, что выполнение миграции требует ресурсов, которые им не выделяют.
Последнее десятилетие характеризуется снижением влияния ИТ-отдела при принятии решений в компаниях. И, я думаю, это не по вине ИТ-отдела. ИТ-специалисты видят риски, связанные с применением каждой технологии, и понимают, что само их предназначение состоит в ограничении влияния этих рисков на компанию, в которой они работают. Все последнее десятилетие многие крупные ИТ-компании пропагандировали идею, что у них есть особый подход к ИТ и они обладают всем необходимым для снижения рисков от использования тех или иных технологий в бизнесе. Они с уверенностью убеждали нетехнических руководителей, что у них развернута своя надежная инфраструктура, что они избавят компании от всех трудностей работы с ИТ, надо просто заплатить провайдеру «облачных» услуг. Такой аргумент помогает им продавать подписки на «облачные» службы, но он же намекает на то, что к ИТ-специалистам прислушиваться не нужно.
Те же самые представители ИТ-компаний объясняют «нетехническим» сотрудникам, что они смогут пользоваться своими дорогими переносными компьютерами на работе без всякого присмотра со стороны ИТ-отдела, что намного удобнее хранить конфиденциальные документы в общедоступном «облачном» хранилище и что пользователи смогут отправлять такие конфиденциальные документы через бесплатные почтовые службы, а не с помощью серверов Exchange, на которых настроены политики предотвращения утечек конфиденциальной информации Data Loss Prevention. Так последние десять лет крупные ИТ-компании приучали нетехнических пользователей к тому, что они могли бы делать все, что им заблагорассудится, когда дело касается информационных технологий, и что предназначение ИТ-отделов со всеми их правилами и политиками состоит в том, чтобы не мешать этому, а защищать компанию только от реальных угроз. И по мере усиления восприятия ИТ как «нужной игрушки», компании стали относиться к ИТ не как к полезному активу, а как к вспомогательной второстепенной службе, чьи запросы можно отложить на потом.
Так что неудивительно, что, когда ИТ-персонал годами повторяет, что компании нужно отказываться от использования Windows Server 2003, ее руководство игнорирует этот факт просто потому, что поставщики «облачных» служб уверяют, будто ИТ-специалистами и их запросами можно пренебречь.
Когда проблема не видна
Нет сомнений в том, что работа с существующей вот уже более 14 лет и неподдерживаемой Windows Server 2003 создает много проблем. Но у многих компаний тем не менее есть задачи и поважнее, чем разбираться с неподдерживаемой производителем операционной системой, которая все еще выполняет свою работу. Одним из основных умений любого системного администратора является способность расставить приоритеты. Прежде всего он решает наиболее серьезные проблемы и обращается к менее важным несколько позже. Если только что «упал» контроллер домена, то большинство системных администраторов не побежит сперва чинить мышь сотруднице отдела маркетинга.
Тот факт, что серверы Windows Server 2003 нуждаются в замене, не новость ни для кого из ИТ-подразделения. Если компания не имеет специального соглашения с Microsoft, то эта операционная система не поддерживается должным образом и работа с ней влечет за собой больше рисков, чем работа с поддерживаемой и своевременно обновляемой системой. Однако с точки зрения учета важности проблем то, что Windows Server 2003 не поддерживается, возможно, менее значимо, чем решение наиболее насущных для системного администратора в данный момент проблем. Для многих из тех, кто использует Windows Server 2003 в рабочей среде, миграция пока еще имеет статус «сделать желательно», а не «сделать срочно». Вполне возможно, что в общей цепочке задач ИТ-отдела есть куда более слабые звенья, которые требуют внимания в первую очередь. И то, что серверы с Windows Server 2003 еще находятся в эксплуатации, еще, возможно, не самое слабое звено.
Вполне вероятно, например, что возникла необходимость в замене критически важного для компании приложения, сбой в работе которого реально будет стоить больших денег именно сейчас. А гипотетические издержки от использования несоответствующей отраслевым нормам операционной системы могут возникнуть только при проведении аудита. Или, например, необходимо срочно в рамках всей компании решить проблемы со слабыми паролями пользователей на руководящих должностях или их доступом к файловым ресурсам.
Поэтому, вместо того чтобы приписывать компаниям упорное стремление к использованию Windows Server 2003, в то время как все знают, что операционная система не поддерживается, следует предположить, что почти все системные администраторы желают отказаться от нее, а сокращение штата и недостаток ресурсов приводят к тому, что им приходится иметь дело с большим числом текущих задач и откладывать менее важную проблему на потом.
Периметр не обеспечивает полной безопасности
Нахватавшиеся обрывков сведений о безопасности руководители компаний сами представляют определенную опасность. Например, они могут быть уверены в том, что размещение сервера с Windows Server 2003 под защитой сетевого экрана означает, что теперь его нельзя взломать удаленно. Но на самом деле даже системы за сетевым экраном все еще подвергаются риску. Атаки на такие системы могут исходить от пользователей внутри сетевого периметра или от компьютера изнутри сети, который был скомпрометирован с помощью других методов проникновения и использован в качестве посредника для атаки на остальные компьютеры в сети.
Специалисты института Понемона (http://www.ponemon.org/) в ходе исследования обнаружили, что около 30% атак исходят от внутренних пользователей. И размещение сетевого экрана между сервером и общедоступной сетью обеспечивает только защиту от атак из общедоступной сети, но не оказывает никакого влияния на безопасность, если атака возникает в сети. И, хотя, конечно, можно создать и настроить отдельную изолированную сеть внутри корпоративной сети, в которой будут находиться только серверы, выполняющие Windows Server 2003, скорее всего, будет дешевле выполнить обновление серверов до более новой версии, например до Server 2008 R2 или Server 2012 R2.
Обновление к последней версии?
Выше я упоминал, что компании, возможно, будут переходить от Windows Server 2003 к Windows Server 2008 R2 или 2012 R2. Кто-то может не согласиться и задуматься, а не лучше ли перейти сразу на версию 2016. Ведь причины для этого очевидны: каждая последующая версия создается с учетом уроков, извлеченных из использования предыдущих версий. Windows Server 2008 R2 — более безопасная версия операционной системы, чем 2008, Windows Server 2012 более безопасна, чем 2008 R2, а Windows Server 2012 R2 учитывает все проблемы, обнаруженные при эксплуатации Windows Server 2012. А уж использование Windows Server 2016 еще более надежно, чем Windows Server 2012…
Я не совсем согласен с этим. Прежде чем выполнить переход к новой операционной системе, ее следует предварительно достаточно хорошо изучить и получить навыки работы с ней. И обязательно необходимо наличие инструментов, способных помочь в выполнении такого перехода. Если у вас в планах стоит переход к Windows Server 2016 от версии Windows Server 2003, то, скорее всего, вы не найдете бесплатных инструментов, помогающих в выполнении такой миграции, поскольку, по представлениям Microsoft, миграции подобного типа должны были быть выполнены до окончания срока поддержки Windows Server 2003.
Соответствие требованиям по соглашению
Как я уже рассказывал выше, на одной из конференций в ответ на вопрос об использовании Windows Server 2003 в рабочей среде от 30 до 40% пользователей подняли руки из примерно двух сотен участников. А на вопрос о наличии отдельного соглашения с Microsoft на поддержку Windows Server 2003 утвердительно ответили только два человека. Из этой ситуации я уяснил, что для большинства системных администраторов факт соответствия или несоответствия операционной системы Windows Server 2003 отраслевым нормам не имеет большого значения. Они знают, что им придется избавиться от нее, они хотят это сделать, и они не желали тратить время только на то, чтобы иметь возможность поставить несколько галочек в специальной форме, в которой спрашивается о соответствии используемых компанией операционных систем принятым в отрасли нормам, тогда как им известно, что с Windows Server 2003 они будут расставаться.
Способ сделать Windows Server 2003 соответствующей требованиям заключается в обращении к сотрудникам Microsoft и разработке соглашения о поддержке. Часть процесса разработки соглашения включает создание конкретных планов по переходу с Windows Server 2003. Другая часть состоит из ваших обязательств платить Microsoft за поддержку и программные обновления для этой устаревшей операционной системы. Многие из тех администраторов, которым я рассказывал об этом, посчитали, что если бы их компания выделила им средства на такое соглашение о поддержке с Microsoft, то их было бы лучше потратить на выполнение миграции и уход от Windows Server 2003.
Только локально
Запуск системы Windows Server 2003 в «облаке» представляет собой довольно противоречивый проект. Провайдеры «облачных» услуг, несомненно, осведомлены о том, что эта версия больше не поддерживается Microsoft. Некоторые из них, например Amazon Web Services (AWS), позволяют разворачивать новые виртуальные машины с Windows Server 2003 в рамках предложения IaaS. Другие, такие как Azure, не предлагают вариант Windows Server 2003 после окончания поддержки. В документе на сайте AWS (https://aws.amazon.com/windows/faq/#win2003) по поводу Windows Server 2003 отмечается, что в настоящее время запуска этой версии покупателю следует избегать. AWS позволит вам запустить ее, но предупредит, что данная операционная система не поддерживается и что это не совсем правильно, они не смогут помочь, если вы столкнетесь с проблемами.
У большинства специалистов недостаток поддержки Windows Server 2003 «облачными» службами не вызывает затруднений. У них нет намерения переносить локальный экземпляр в «облако». Если бы у них был бюджет на миграцию с Windows Server 2003, они бы не потратили его на создание экземпляра Windows Server 2003 в «облаке». И хотя есть какое-то число экземпляров Windows Server 2003 в «облаке», большинство из них осталось функционировать локально. Такие экземпляры Windows Server 2003 работают скорее на «забытых в углу» старых серверах, но никак не создаются заново в виде виртуальным машин в «облаке».
Помощь гипервизора временна
Тот факт, что вы можете запустить Windows Server 2003 на имеющихся платформах виртуализации, не означает, что вы сможете сделать это в будущем. Когда-то модернизации проводились не только по причине преимуществ нового программного обеспечения, ни и в случае поломок старого аппаратного обеспечения. Одна из многих причин, почему Windows Server 2003 все еще прочно держится в центрах обработки данных многих компаний, состоит в том, что это первая серверная операционная Microsoft, которая устойчиво работала внутри виртуальной машины, а виртуальные машины, как известно, не испытывают неудобств от поломок старого аппаратного обеспечения. Если происходит поломка на хосте виртуализации, то ее либо устраняют, либо нагрузка переносится на новый хост виртуализации. Нет никакой необходимости в обновлении Windows Server 2003, потому что, когда вы запускаете ее на виртуальной машине, эта операционная система абстрагируется от любого аппаратного обеспечения.
Сегодня все основные платформы гипервизора поддерживают Windows Server 2003 в качестве гостевой операционной системы для виртуальной машины. Но не похоже, что так будет всегда. Как показывает выпуск второго поколения виртуальных машин Generation 2 в Hyper-V, несомненно имеются плюсы от реализации новых моделей аппаратных архитектур для виртуальных машин. С определенной точки зрения, пока еще далеко до окончания срока поддержки Windows Server 2008 R2, когда Hyper-V, возможно, прекратит поддерживать виртуальные машины первого поколения Generation 1. Если это произойдет, нельзя будет запускать Windows Server 2003 на текущей версии Hyper-V, и тогда придется вводить в строй устаревшую версию этого продукта для запуска неподдерживаемой операционной системы. Нет также никаких причин верить в то, что остальные поставщики продуктов виртуализации будут и впредь поддерживать Windows Server 2003. Сокращение поддержки будет выражаться в отсутствии обновления драйверов для виртуальных машин Windows Server 2003. Запустить систему Windows Server 2003, возможно, и получится, но использовать ее будет весьма затруднительно.
Приложения тоже устаревают
Более года назад прекратилась поддержка не только Windows Server 2003. Поставщики приложений тоже не желают поддерживать свои продукты для операционной системы, не поддерживаемой производителем. Большинство версий приложений, написанных для Windows Server 2003, не запускаются на Windows Server 2008 R2, 2012 R2 или 2016. Для новых версий операционных систем производители выпустили соответствующие версии своих приложений. Например, версия 6.0 приложения может работать на Windows Server 2003, но не работать на Windows Server 2008, для использующих эту версию серверной операционной системы предназначена версия 7.0. И, скорее всего, во многих случаях версия 7.0 не заработает на Windows Server 2003. Производитель, возможно, поддерживает версию 6.0 для тех пользователей, которые решили пока не выполнять обновление, а версию 7.0 — для тех, кто работает с более новой версией операционной системы.
Производитель приложения будет поддерживать версию 6.0, пока это имеет для него смысл, что во многом зависит от того, приносит ли она достаточную на его взгляд прибыль, но в определенный момент, подобно Microsoft, он «выключит рубильник» и предложит своим клиентам выполнить обновление. Несомненно, большинство поставщиков программ, которые работали на Windows Server 2003, прекратили поддержку своих приложений некоторое время назад. Все еще эксплуатирующим эти приложения компаниям не остается ничего другого, как надеяться, что они не выйдут из строя. Они понимают, что у них в критическом случае запасного выхода нет, и им не остается ничего иного, как только надеяться на «авось» до тех пор, пока приложение перестанет быть нужным.
Забытые разработчиками
Все еще работающие на Windows Server 2003 приложения вряд ли получат обновления от разработчиков. Платформа Windows Server 2003 морально полностью устарела и больше не поддерживается производителем, если только вы не выполните набор строгих условий. А большинство компаний этим условиям не соответствуют. Учитывая, что производители новых платформ напряженно борются за привлечение внимания разработчиков приложений, резонно утверждать, что устаревшая платформа не будет привлекать никакого внимания разработчиков, если только они не занимаются созданием вредоносных программ. Приложения, запущенные на системах Windows Server 2003, в лучшем случае доживают свой срок. А надежно работать с экосистемой, которая доживает свой век, компания вряд ли способна. И единственным путем получить обновленные приложения для нее становится переход на ту платформу, которая развивается. Конечно, для некоторых приложений отсутствие обновлений не имеет особого значения, они выполняют только те операции, которые нужны компании, и пока это так, все идет нормально. Никаких изменений в выполняемых приложением операциях не предполагается, а значит, и никаких обновлений не развертывается. Соответственно и любые ошибки, которые, возможно, были в приложении, так и останутся неисправленными.
Восстановление Windows Server 2003 после сбоя
Эксплуатация операционной системы в производственных условиях предполагает, что вам необходимо иметь возможность ее восстановления в случае, если произойдет что-то катастрофическое. Иметь возможность перестроить сервер означает не просто иметь под рукой операционную систему, но и необходимость получить доступ к драйверам и приложениям. Даже если предполагается выполнение полного восстановления сервера с использованием отдельного решения резервного копирования, все же необходимо иметь возможность выполнить чистую установку сервера, драйверов и приложений, на случай если резервные копии и данные в силу каких-либо причин нельзя будет восстановить. А если вы регулярно выполняете восстановление сервера, то наверняка знаете, что если неприятность может случиться, то она случится обязательно.
Напомню, что, поскольку производители приложений не собираются поддерживать платформу Windows Server 2003 всегда, поставщики решений по резервному копированию и восстановлению также не будут бесконечно долго следить за работоспособностью своих решений по резервированию и восстановлению для Windows Server 2003. И на сегодня уже мало кто из производителей решений для резервирования все еще поддерживает резервирование систем, работающих на операционной системе Windows Server 2003.
Когда вы сохраняете в рабочей среде сервер Windows Server 2003, вам необходимо сохранять и все приложения, которые поддерживают экосистему Windows Server 2003. Это означает сохранение не только приложений, запущенных на сервере, но и версии платформы виртуализации, которая хостирует сервер, и версий драйверов устройств, используемых сервером, и приложений мониторинга и резервного копирования, которые необходимы для обслуживания сервера.
Расстаемся с Server 2003: непрямая миграция
Вероятно, вам приходилось слышать о «теневых» ИТ. В подобном случае пользователи обходят политики ИТ-подразделения и организуют собственные серверы в «облаке» или используют публичные службы доступа к файлам для хранения рабочих файлов. ИТ-подразделения, скованные медлительностью руководства при переходе с Windows Server 2003, пытаются отчасти взять дело в свои руки.
Я никогда не рекомендую совершать шагов, за которые можно поплатиться увольнением или административным взысканием, но если в вашей компании сложилось лояльное отношение к «теневым ИТ», то можно обдумать меры по переносу рабочих нагрузок с Windows Server 2003 даже без официального разрешения.
Например, многие администраторы серверов даже не начинают думать о способах миграции, пока не получат «зеленый свет». Если вы сможете составить план необходимых действий или даже провести пробную миграцию в лаборатории, то, получив разрешение на миграцию, далеко опередите специалистов, пассивно ожидавших одобрения начальства.
Устаревшие серверы
В некоторых компаниях компьютеры работают с серверами Windows Server 2003 не потому, что на них размещены критические рабочие нагрузки, не подлежащие миграции, а потому, что те оказались забытым устаревшим ящиком в центре обработки данных.
Недавно я услышал шутку о сотруднике интернет-компании, который позвонил самому давнему клиенту, чтобы поблагодарить за верность компании в течение двадцати с лишним лет. Самый давний клиент был удивлен, поскольку полагал, что договор утратил силу более десяти лет назад. Нередко администраторы организуют новую службу или размещают рабочее приложение, а потом просто забывают об их существовании.
В ходе недавнего исследования, проведенного по заказу компании, продающей решение для мониторинга в центрах обработки данных, выяснилось, что до 30% рабочих приложений пребывают в коматозном состоянии. Компания, поставляющая продукт для мониторинга в центре обработки данных, несомненно заинтересована в том, чтобы потребители обеспокоились наличием бесполезных серверов (и заплатили, чтобы найти у себя простаивающее оборудование). Однако опыт свидетельствует, что проблема все еще реальна.
Когда администраторы серверов осуществляли инвентаризацию серверов Windows Server 2003, чтобы определить, кто выполняет рабочие приложения при подготовке к замене операционной системы, оказалось, что на многих серверах нет владельцев рабочего приложения или владелец рабочего приложения совершенно забыл о сервере.
Не составляет труда распорядиться этими рабочими приложениями после того, как их состояние определено. Однако компаниям, по-видимому, следует прислушаться к советам поставщика продуктов для мониторинга в центре обработки данных и продумать метод обнаружения устаревших серверов, прежде чем они будут удалены из центра обработки данных потому, что срок эксплуатации их операционной системы завершен.
Недостаточно эффективное управление
Еще один довод в длинном списке аргументов в пользу отказа от Windows Server 2003: функции управления Windows Server 2003 менее эффективны, чем в новых версиях Windows Server. Новые версии Windows Server гораздо более управляемые и лучше автоматизируемые, чем старые версии Windows Server. Отчасти это объясняется тем, что лишь в недавно выпущенных версиях Windows Server стало ощутимым влияние «смены парадигмы администрирования на PowerShell». Можно сказать проще: смена парадигмы заключается в том, что PowerShell перестал быть одним из возможных способов выполнения задачи и стал оптимальным вариантом. Из этого не следует, что PowerShell — лучший на сегодня способ выполнения любых задач на Windows Server. Но я полагаю, что с каждой последующей версией Windows Server увеличивается число сценариев, для которых PowerShell — лучший вариант.
Безусловно, PowerShell можно использовать с Windows Server 2003, но разработчики Windows Server 2003 не рассчитывали на PowerShell как на основной инструмент администрирования. Достаточно взглянуть на Nano Server и многие компоненты Windows Server 2016, чтобы понять, что PowerShell, вероятно, будет вашим предпочтительным вариантом, а применение других инструментов станет скорее исключением, а не правилом.