Op dit moment heb ik het genoegen om te mogen werken met een grote hoeveelheid Public Folder data. Het doel is om deze te repliceren naar nieuwe databases. Hierbij gebruik ik een aantal scripts en tools die misschien handig zijn om te delen.
Overzicht
Als eerste heb ik een Excel-file gemaakt met een overzicht van alle folders, het aantal items hierin en de grootte in MB. Dit is weliswaar een momentopname maar het geeft je een goed beeld van de structuur en de grootste folders.
Get-PublicFolder -Recurse -ResultSize Unlimited | Get-PublicFolderStatistics | Select-Object Name,FolderPath,CreationTime,LastAccessTime,LastModificationTime,LastUserModificationTime,LastUserAccessTime,@{expression={$_.totalitemsize.value.ToMB()};label=”Size(MB)”},ItemCount | Export-CSV "C:\data\pfstats.csv"
Denk aan de -ResultSize parameter, anders krijg je met Get-PublicFolder alleen de eerste 10.000 resultaten. Dit bestand heb ik in Excel geopend, conditional formatting gebruikt om folders met veel items of data snel te kunnen herkennen en uiteraard opgeslagen als xlsx-bestand.
Aan de hand van dit bestand heb ik de top-level folder kunnen kiezen waarmee ik de replicatie wil starten. Ook heb ik kolommen toegevoegd voor de nieuwe databases zodat ik een check kan zetten als ik deze als replica toegevoegd heb. Dit helpt mij om overzicht te houden gedurende het proces.
Replica's toevoegen of verwijderen
Op de locatie waar Exchange geïnstalleerd is staat een \scripts directory. Omdat het installatiepad per server verschilt is er de $exscripts een variabele die we in Exchange Management Shell kunnen gebruiken om de scripts te lokaliseren.
In dit geval gebruik ik het AddReplicaToPFRecursive.ps1 script om de nieuwe database als replica toe te voegen op een toplevel folder en alle onderliggende folders:
cd $exscripts
./AddReplicaToPFRecursive.ps1 -TopPublicFolder "\MyFolder" -ServerToAdd NewServer1
Op een later moment gebruik ik het RemoveReplicaFromPFRecursive.ps1 om de oude replica te verwijderen. Een alternatief zou het gebruik van het MoveAllReplicas.ps1 script die beide stappen in één keer doet. Meer informatie over deze scripts vind je hier: Scripts for Managing Public Folders in the Exchange Management Shell
Rapportage en monitoring
Om op hoofdlijnen te zien op de replicatie plaats vindt, gebruik ik het volgende commando die de grootte van het .edb-bestand geeft:
Get-PublicFolderDatabase | Select Server, Name, @{Name="Size (GB)";Expression={$objitem = (Get-PublicFolderDatabase $_.Identity); $path = "`\`\" + $objitem.server + "`\" + $objItem.EdbFilePath.DriveName.Remove(1).ToString() + "$"+ $objItem.EdbFilePath.PathName.Remove(0,2); $size = ((Get-ChildItem $path).length)/1048576KB; [math]::round($size, 2)}}, @{Name="Size (MB)";Expression={$objitem = (Get-PublicFolderDatabase $_.Identity); $path = "`\`\" + $objitem.server + "`\" + $objItem.EdbFilePath.DriveName.Remove(1).ToString() + "$"+ $objItem.EdbFilePath.PathName.Remove(0,2); $size = ((Get-ChildItem $path).length)/1024KB; [math]::round($size, 2)}}
Deze one-liner ziet er misschien complexer uit dan hij is, dat komt omdat we het UNC pad moeten samenstellen om de grootte van het bestand te kunnen meten. Een andere stukje code is om de grootte om te rekenen naar GB en MB.
Door dit commando af en toe te herhalen zie je al snel dat het aantal GB's van de nieuwe databases toeneemt. Dit is natuurlijk niet voldoende om een goed beeld van de status te krijgen. Dus na enige tijd heb ik het Exchange 2010 Public Folder Replication Report van Mike Walker gebruikt.
Dit script gebruikt Get-PublicFolder en Get-PublicFolderSatistics om informatie over de public folders te vergaren. Omdat dit zeer lang kan duren, al snel enkele uren bij een paar duizend folders, beperkt ik het rapport tot een specifieke top-level folder:
.\Get-PublicFolderReplicationReport.ps1 -FolderPath "\MyFolder" -Recurse -ComputerName @("OldServer1", "OldServer2", "NewServer1", "NewServer2") -AsHTML -Filename report.html
Het resultaat is een zeer bruikbaar rapport in HTML-vorm.
Troubleshooting
Op basis van de bestandsgrootte was al duidelijk dat één van de nieuwe databases niet volledig gevuld werd en het HTML-rapport bevestigt dat. Om uit te vinden of er een probleem is heb ik het logging level voor een aantal relevante bronnen op de bron- en doelserver aangepast van Lowest naar High:
Set-eventloglevel -Identity "OldServer1\MSExchangeIS\9001 Public\Replication Incoming Messages" -level high
Set-eventloglevel -Identity "OldServer1\MSExchangeIS\9001 Public\Replication Outgoing Messages" -level high
Set-eventloglevel -Identity "OldServer1\MSExchangeIS\9001 Public\Replication NDRs" -level high
Set-eventloglevel -Identity "OldServer1\MSExchangeIS\9001 Public\Replication Backfill" -level high
Set-eventloglevel -Identity "OldServer1\MSExchangeIS\9001 Public\Replication Errors" -level high
Set-eventloglevel -Identity "OldServer1\MSExchangeIS\9001 Public\Replication General" -level high
Set-eventloglevel -Identity "NewServer1\MSExchangeIS\9001 Public\Replication Incoming Messages" -level high
Set-eventloglevel -Identity "NewServer1\MSExchangeIS\9001 Public\Replication Outgoing Messages" -level high
Set-eventloglevel -Identity "NewServer1\MSExchangeIS\9001 Public\Replication NDRs" -level high
Set-eventloglevel -Identity "NewServer1\MSExchangeIS\9001 Public\Replication Backfill" -level high
Set-eventloglevel -Identity "NewServer1\MSExchangeIS\9001 Public\Replication Errors" -level high
Set-eventloglevel -Identity "NewServer1\MSExchangeIS\9001 Public\Replication General" -level high
Na enige tijd verschijnen er in het Application eventlog allerlei meldingen van source MSExchangeIS Public Store. Op zich zou ik die met PowerShell kunnen analyseren (Get-EventLog) maar voor een snel overzicht heb ik de Event Viewer gemaakt en een filter op source MSExchangeIS Public Store gezet.
De grote hoeveelheid errors bleken vals alarm te zijn, deze waren onschuldig en geen indicatie voor een daadwerkelijk probleem.
Om eventuele fouten te repliceren heb ik de replicatie voor een (op de nieuwe server niet gevulde) folder handmatig gestart:
Update-PublicFolder "MyFolder\SubFolder" -Server OldServer1
Op dit moment zie je direct de bijbehorende replicatie-events verschijnen op de bron- en doelserver. Vervolgende de statistieken voor deze folder opgevraagd op de oude en nieuwe server:
Get-PublicFolderStatistics "MyFolder\SubFolder" -Server OldServer1
Get-PublicFolderStatistics "MyFolder\SubFolder" -Server NewServer1
Na een paar minuten gaf de folder op de nieuwe server het zelfde aantal items als de oude. Daarom ook de rest van de folders nogmaals laten updaten:
Get-PublicFolder "MyFolder\SubFolder" -Recurse -ResultSize Unlimited | Update-PublicFolder -Server OldServer1
Daarna het Public Folder Replication Report nogmaals uitgevoerd en uitsluitend groene vlakjes gezien.
Tips
Met name bij het werken met grote hoeveelheden folders duren eenvoudige taken als het opvragen van folders of statistieken zeer lang. Plan dus vooruit en voorkom dat je langlopende taken opnieuw moet uitvoeren. Sla het resultaat van een query op in een CSV-bestand of variabele.
Deel de hoeveelheid data op in behapbare blokken, bijvoorbeeld een toplevelfolder met onderliggende mappen die voldoende items bevatten maar pakweg een paar GB groot zijn. Selecteer hiervoor desnoods een dieper gelegen folderstructuur. Besteed aandacht aan het verloop en zorg dat je goed inzicht hebt in het verloop of eventuele problemen. Los die eerst op en ga dan verder met de rest van de data.
Dit artikel heeft betrekking op Exchange 2010 maar is ook bruikbaar voor Exchange 2007. Om Public Folder replicatie goed te begrijpen moeten we terugvallen op documentatie voor Exchange 2003, afgezien van de gebruikte tools is er in Exchange 2007 en 2010 namelijk weinig veranderd. Een goed stuk documentatie is: Controlling Exchange Server 2003 Public Folder Replication
No comments:
Post a Comment