CZ 
06.10.2024 Hanuš VÍTEJTE V MÉM SVĚTĚ

Přechod z Exchange 2007 na Exchange 2010 - část 2

| Petr Bouška - Samuraj |
V minulém díle jsme začali tím, že jsme nainstalovali nový Exchange Server 2010 do naší organizace, a snad vyřešili všechny problémy a komplikace. Dnes budeme pokračovat vlastní migrací z původního serveru s verzí 2007 na nový. Protože se nový server stal součástí existující Exchange organizace, tak převzal hlavní nastavení. Celý postup si uvedeme pouze bodově a podrobněji se budeme věnovat pouze pár oblastem.
zobrazeno: 10 729x | Komentáře [0]

Postup migrace

Pokud plánujeme nasadit nový Exchange na více serverů pro vyšší dostupnost, tak můžeme využít nových možností, které přináší Database Availability Group (DAG) a Client Access Server Array (CAS Array). Těmto technikám jsem se stručně věnoval v článku Exchange 2010 CAS Array a DAG mezi Sites a zde je nebudeme uvažovat.

Vycházíme z toho, že jsme splnili všechny předpoklady a máme korektně nainstalovaný Exchange Server 2010 (přičemž proběhlo i povýšení schématu AD). Nový server se jmenuje Exch2010 a obsahuje všechny role, starý server má jméno Exch2007. Servery mají nastaveny IP adresy a korektní záznamy v DNS interní domény firma.local.

Pozn.: Pro běžné termíny využívám zkratky, často používaná je Exchange Management Console = EMC.

  • Vytvoříme novou databázi pro schránky a veřejné složky nebo využijeme ty, které vznikly při instalaci, a nastavíme jejich parametry (například Storage limits a jakou databázi veřejných složek upřednostňuje).
  • Pokud jsme vytvořili nové DB, tak přesuneme systémové schránky z originální DB a smažeme původní databáze.
  • Jestli jsme tak neučinili minule, tak vydáme a nastavíme certifikát pro CAS (EMC - Server Configuration - vybereme server a vpravo jsou možnosti).
  • Nastavíme repliky veřejných složek do nové databáze.
  • Na novém serveru nakonfigurujeme OWA, Outlook Anywhere, ActiveSync, ECP, OAB, POP3/IMAP, Recieve Connectory
  • .
  • Změníme nastavení (rehome) pro generování Offline Address Book (OAB) na Exch2010. V EMC - Organization Configuration - Offline Address Book - Default Offline Address Book - Move, případně v konfiguraci povolit webovou distribuci.
  • Přesměrujeme provoz SMTP, OWA, Outlook Anywhere apod. na FW na nový server.
  • Upravíme Send Connector, jako Source Server přidáme Exch2010.
  • Případně upravíme/nastavíme Edge Subscription.
  • Přesuneme postupně uživatelské schránky.
  • Přesuneme repliky veřejných složek na nový server = odstraníme na původním serveru.
  • Smažeme databáze schránek a PF na Exch2007.
  • Na Send Connector odstraníme server Exch2007 jako Source Server.
  • Odinstalujeme Exchange z Exch2007 pomocí klasické odinstalace, přitom odškrtáme všechny role.

Přidání PowerShell Snapinu

Pokud chceme využít Exchange příkazy nejen v Exchange Management Shell, ale třeba v PowerShell ISE na stanici (kde máme nainstalované Exchange Management Tools), tak nejprve musíme načíst Snapin.

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010

Přesun systémových schránek do nové DB

Osobně mi připadá čistší vytvořit nové databáze pro schránky a veřejné složky, kdy jim rovnou můžeme nastavit přehledná jména a lokace pro umístění souborů DB a logů (na různých discích). Potom ale musíme přesunout systémové schránky, které se automaticky vytvořili v první DB schránek.

Jde o Discovery Search Mailbox a tři Arbitration schránky, dvě začínají jménem SystemMailbox (mají DisplayName Microsoft Exchange Approval Assistant, Microsoft Exchange) a třetí FederatedEmail (s DisplayName Microsoft Exchange Federation Mailbox). Tyto schránky musíme přesunout do nové DB, aby se ta původní dala smazat. Discovery Search Mailbox můžeme přesunout pomocí EMC, ale systémové schránky tam nevidíme a musíme použít PowerShell. Nejprve si zjistíme jméno původní DB.

[PS] C:\>Get-MailboxDatabase
Name                           Server          Recovery        ReplicationType
----                           ------          --------        ---------------
Mailbox Database 1308616801    EXCH2010        False           Remote
DBmail                         EXCH2010        False           Remote

Potom vypíšeme seznam Arbitration schránek.

[PS] C:\>Get-Mailbox -Database EXCH2010 -Arbitration
Name                      Alias                ServerName       ProhibitSendQuota
----                      -----                ----------       -----------------
SystemMailbox{1f05a927... SystemMailbox{1f0... Exch2010         unlimited
SystemMailbox{e0dc1c29... SystemMailbox{e0d... Exch2010         unlimited
FederatedEmail.4c1f4d8... FederatedEmail.4c... Exch2010         1 MB (1,048,576 bytes)

A přesuneme jednotlivé schránky do nové DB.

New-MoveRequest -Identity "FederatedEmail.4c133d8b-8659-4148-93bf-005a1fa1e042" -TargetDatabase DBmail

Potom můžeme smazat původní databázi schránek, třeba pomocí EMC - Organization Configuration - Database Management.

Přesun veřejný složek - Public Folders (PF)

Microsoft se stále snaží opustit PF a na Exchange 2010 je již téměř nepotřebujeme. Pro pár věcí se ale stále používají, více informací nalezneme v dokumentaci Understanding Public Folders - Public Folder Trees.

Na novém serveru máme připravenu novou databázi pro veřejné složky (DBPF). Při jejím vytvoření se do ní automaticky zreplikovala struktura/hierarchie (Public Folder Hierarchy) veřejných složek. Ale neobsahuje žádná data. Pokud by ji klient použil, tak se dozví informaci, kam se pro data připojit. Proto musíme nastavit replikaci dat, počkat až proběhne a pak ji zrušit na původním serveru.

Přidání repliky

Potřebujeme nastavit ke všem složkám, které v Public Folders máme, aby se replikovaly do nové DB. To můžeme provést ručně pomocí Public Folder Management Console. Nebo efektivněji pomocí skriptu v PowerShellu, který MS připravil již pro Exchange 2007.

Skript doporučuji spustit z nového Exch2010 serveru (když jsem jej pustil na 2007, tak se mi nastavila replikace pouze na třetinu složek). Standardně se nachází v cestě.

C:\Program Files\Microsoft\Exchange Server\V14\Scripts

A volat jej můžeme následovně (pokud použijeme parametr -? tak dostaneme nápovědu).

.\AddReplicaToPFRecursive.ps1 -TopPublicFolder "\" -ServerToAdd Exch2010

Skript provede to, že od zadané složky (u nás kořen) přidá do nastavení replikací PF databázi na zadaném serveru. Pak se teprve spustí replikace, která může trvat mnoho hodin.

V různých diskuzích se ještě uvádí, že je potřeba také replikovat systémové složky NON_IPM_SUBTREE (oproti tomu defaultní složky se označují IPM_SUBTREE), ale tyto složky jsou ve skriptu schválně vynechány. A až budeme v dalším kroku přesouvat PF na nový server, tak se převedou i tyto systémové složky.

Na seznam systémových složek (které obsahují třeba OAB a Free/Busy informace, které již nepotřebujeme pro Outlook 2007/2010) se můžeme podívat příkazem.

Get-PublicFolder -Identity \NON_IPM_SUBTREE -Recurse

Potom, co jsme přidali repliky k PF, můžeme zkontrolovat, že se opravdu nastavily. Pro informace o PF máme k dispozici dva cmdlety Get-PublicFolder, který pracuje obecně se strukturou veřejných složek, nebo Get-PublicFolderStatistics, který pracuje přímo s PF na daném serveru. Můžeme si vypsat seznam složek a nastavení replik (první příklad), ideálně do souboru, a pak pohledem zjistit, jestli někde nechybí replika. Případně přidat do dotazu podmínku a vypsat složky, kde není nastavena daná databáze (druhý příklad).

Get-PublicFolder -Recurse | FT Name, Replicas -AutoSize | Out-File -FilePath c:\pf.txt -Width 600
Get-PublicFolder -Recurse | where { !($_.Replicas -like "*DBPF*") } | FT Name, Replicas

Jiná možnost pro kontrolu, je spočítat počet složek na starém a novém serveru. Musíme použít cmdlet Get-PublicFolderStatistics, který vidí pouze složky na daném serveru. Ten nám ale na původním serveru bude vypisovat i systémové složky, které jsme nereplikovali. Abychom dostali rozumný výsledek, tak musíme výstup omezit. U mne fungoval následující příkaz.

(Get-PublicFolderStatistics -Server Exch2007 -ResultSize Unlimited | where { !($_.FolderPath -like "SCHEDULE*") -and 
 !($_.FolderPath -like "OFFLINE ADDRESS BOOK*") -and !($_.FolderPath -like "StoreEvents*") -and 
 !($_.FolderPath -like "OWAScratchPad*") -and !($_.FolderPath -like "schema-root*")} | Measure-Object).Count

(Get-PublicFolderStatistics -Server Exch2010 -ResultSize Unlimited | where { !($_.FolderPath -like "SCHEDULE*") -and
 !($_.FolderPath -like "OFFLINE ADDRESS BOOK*") -and !($_.FolderPath -like "StoreEvents*") -and
 !($_.FolderPath -like "OWAScratchPad*") -and !($_.FolderPath -like "schema-root*")} | Measure-Object).Count

Pokud nejsou hodnoty stejné, tak si můžeme vypsat seznam složek na obou serverech do souborů (zdejší příklad je bez vynechání systémových složek) a pomocí nějaké aplikace porovnat jejich obsah, čímž bychom měli dostat seznam složek, kde nejsou nastavené replikace.

Get-PublicFolderStatistics -ResultSize Unlimited -Server Exch2007 | FT Name | Out-File c:\PF1.txt
Get-PublicFolderStatistics -ResultSize Unlimited -Server Exch2010 | FT Name | Out-File c:\PF2.txt

Nyní máme na všech složkách nastaveny replikace. Teď potřebujeme zkontrolovat, že replikace již proběhly. Můžeme si vypsat jednotlivé složky včetně jejich obsahu.

Get-PublicFolderStatistics -ResultSize Unlimited | FT Name, FolderPath, ItemCount, TotalItemSize

Ale pro přehled můžeme pouze sečíst počet položek nebo celkovou velikost, postupně na obou serverech.

Get-PublicFolderStatistics -Server Exch2007 -ResultSize Unlimited | where { !($_.FolderPath -like "SCHEDULE*") -and
 !($_.FolderPath -like "OFFLINE ADDRESS BOOK*") -and !($_.FolderPath -like "StoreEvents*") -and
 !($_.FolderPath -like "OWAScratchPad*") -and !($_.FolderPath -like "schema-root*")} | Measure-Object -Sum -Property ItemCount

Get-PublicFolderStatistics -Server Exch2007 -ResultSize Unlimited | where { !($_.FolderPath -like "SCHEDULE*") -and 
!($_.FolderPath -like "OFFLINE ADDRESS BOOK*") -and !($_.FolderPath -like "StoreEvents*") -and !($_.FolderPath -like "OWAScratchPad*") -and 
!($_.FolderPath -like "schema-root*")} | %{$_.TotalItemSize.Value.ToMB()} | Measure-Object -Sum

Přesun repliky

Potom, co máme PF zreplikované, tak můžeme zrušit jejich repliku na starém serveru. Opět využijeme skript, který provede přesun na nové místo (kde již většinu složek máme) a odstranění na místě původním. Skript může běžet dost dlouho. Opět se standardně nachází v cestě C:\Program Files\Microsoft\Exchange Server\V14\Scripts. Jako parametry zadáme původní a nový server.

.\MoveAllReplicas.ps1 -Server Exch2007 -NewServer Exch2010

Když skript běží, tak nám nedává žádný výstup. Abychom zjistili, že se něco děje, tak si můžeme průběžně zobrazovat počet složek na starém serveru. Ten by se měl časem zmenšovat (po spuštění skriptu trvá několik minut, než dojde k první změně).

(Get-PublicFolderStatistics -ResultSize Unlimited -Server Exch2007 | Measure-Object).Count

Potom, co skončí běh skriptu (který mění nastavení na složkách), ještě dlouho běží vlastní replikace (přesouvání dat). Takže musíme čekat do té doby, než bude počet položek na Exch2007 roven nule.

Problém s přesunem replikací

Narazil jsem na problém, kdy po několika hodinách byl počet složek na Exhc2007 roven jedna a i po dalším dni se na původním serveru nacházela jedna složka. Jednalo se o složku

\NON_IPM_SUBTREE\SCHEDULE+ FREE BUSY\EX:/o=firma/ou=First Administrative Group

First Administrative Group je pozůstatek z Exchange Server 2003, od verze 2007 se používá defaultní Exchange Administrative Group. I když jsem pomocí cmdletu Get-PublicFolder vypsal informace o této složce, tak zde není uvedeno, že by na Exch2007 byla její replika. Složka má také nastaven ExpiryTime v minulosti. Tato složka nejde smazat (chyba zní, že je buď špatný název, nebo nejsou dostatečná práva) a díky tomu nejde smazat ani PF databáze.

Zkusil jsem řadu věcí neúspěšně. Nakonec nevím jistě, co pomohlo, ale najednou byla původní DB prázdná. Naposled jsem zkoušel tuto složku smazat na novém serveru, to trvalo dost dlouho a nakonec opět vypsal chybu. Po nějaké době jsem se podíval do DB na starém serveru a ta byla prázdná. Když jsem následně odstraňoval DB v EMC na Exch2007, tak jsem dostal chybu, že DB byla vytvořena v novější verzi Exchange serveru a tudíž zde nelze smazat. Na Exchange 2010 ji EMC nezobrazuje. Nakonec pomohl PowerShell na Exchange 2010 a příkaz Remove-PublicFolderDatabase.

Pozn.: Na internetu jsem narazil na řadu diskuzí, kde řeší podobný problém. Většinou končí radou, aby se použil ADSIEDIT.msc a pomocí něj se smazal záznam o Public Folder Store z AD.

Problém po přesunu replik

Objevil se mi ještě jeden problém po té, co se odstranili repliky na původním serveru. Pokud někdo navázal SMTP spojení se serverem Exch2007 a zkusil odeslat email do PF, tak se to nezdařilo a dostal chybovou zprávu.

504 5.7.1 Not authorized to send RDST

Ostatní zprávy chodili bez chyb, a pokud se posílalo přes nějaký Exchange 2010, tak zprávy dorazili korektně i do veřejných složek. Takže jsem situaci dál neřešil.

Konfigurace služeb

Ne všechna nastavení na novém serveru se nám nastaví tak, jako na současném. Řada z nich je v sekci Server Configuration a nastavují se pro každý Exchange server samostatně. Sem spadá konfigurace služeb, jako je OWA, Outlook Anywhere, ActiveSync, ECP, OAB, POP3/IMAP, Recieve Connectory. Tyto věci musíme nastavit podle původního serveru. Příkladem je autentizace pro OWA, kde se defaultně nastaví form-based, i když ji nepoužíváme (nebo používáme na TMG). Takže upravíme Server Configuration - Client Access - Outlook Web App.

Přesun schránek

Přesun schránek můžeme provést pomocí PowerShell cmdletu New-MoveRequest nebo pohodlně pomocí EMC a jeho průvodce. Pokud používáme jako klienty Outlook 2007/2010, tak by neměl být problém provádět přesun za provozu.

V EMC se přesun provádí v Recipient Configuration - Mailbox, zde označíme jednu nebo více schránek a přes pravé tlačítko (nebo v Actions menu) zvolíme New Local Move Request. Vybereme cílovou databázi, kolik chyb na schránce může nastat, a proces započne. Potom se můžeme podívat do Recipient Configuration - Move Request, kde vidíme aktuální stav přesunu a můžeme si i zobrazit detailní log o přesunu (to se hodí hlavně, pokud dojde při přesunu k chybě).

Problém s OAB

Ještě jsem narazil na jeden problém. Po přesunu na nový Exchange server se klientům nedařilo stáhnout Offline Address Book. Outlook se stále snažil stahovat, ale zůstával na 50%. Pokud jsme otevřeli adresu OAB v prohlížeči (můžeme ji zjistit třeba z Outlooku z Test E-mail AutoConfiguration), tak se zobrazila chyba.

500 - Internal Server Error

Místo standardní

403 - Forbidden: Access is denied

Řešením bylo nastavení práv na soubor web.config, což je popsáno v článku Modify permissions on the Offline Address Book web.config file.

Související články:

Microsoft Exchange

Skoro od začátku mé praxe se věnuji administraci poštovního serveru od firmy Microsoft, tedy Exchange Serveru. Začínal jsem na verzi 2003 a dostal se až k Exchange Online. Články popisují mnoho oblastí správy. Nejvíce od migrace na Exchange Server 2016 a jeho kompletní konfiguraci. Ale také Exchange Hybrid a bezpečnost elektronické pošty.

Pokud se chcete vyjádřit k tomuto článku, využijte komentáře níže.

Komentáře

Zatím zde nejsou žádné komentáře.

Přidat komentář

Vložit tag: strong em link

Vložit smajlík: :-) ;-) :-( :-O

Nápověda:
  • maximální délka komentáře je 2000 znaků
  • HTML tagy nejsou povoleny (budou odstraněny), použít se mohou pouze speciální tagy (jsou uvedeny nad vstupním polem)
  • nový řádek (ENTER) ukončí odstavec a začne nový
  • pokud odpovídáte na jiný komentář, vložte na začátek odstavce (řádku) číslo komentáře v hranatých závorkách