![[RSS]](https://tweakers.net/g/if/v2/icons/rss_small.png){kind=icon}
Let op: Tweakers stopt per 2023 met Tweakblogs. In
dit artikel
leggen we uit waarom we hiervoor hebben gekozen.
Mailbox statistieken
Voor een klant ben ik bezig met een overzicht van de Top15 mailboxen in hun organisatie. Aangezien ze al een script van Steve Goodman hebben draaien met een mooi overzicht van hun omgeving heb ik besloten wat Powershell code toe te voegen aan dat script.
De volgende oneliner leek me handig om later via HTML de output weer te geven:
In de testomgeving was het allemaal geen probleem maar in productie was de hoeveelheid mailboxen een probleem waardoor Powershell me de volgende foutmelding teruggaf:
Na een nachtje slapen besloten om de boel eerst per server af te handelen en vervolgens een totaalstaatje te maken. Dat levert het volgende stukje op:
Voordeel was ook nog eens dat de verwerking een stuk sneller ging.
Eindresultaat is verwerkt in het EnvironmentReport script van Steve Goodman (aanrader wat mij betreft)
De volgende oneliner leek me handig om later via HTML de output weer te geven:
PowerShell:
1
| $mailboxsizes = get-mailbox -resultsize unlimited| Get-MailboxStatistics |Sort-Object TotalItemSize -Descending | Select-Object DisplayName,TotalItemSize -First 10 |
In de testomgeving was het allemaal geen probleem maar in productie was de hoeveelheid mailboxen een probleem waardoor Powershell me de volgende foutmelding teruggaf:
Na wat tips van Tweakers uitgezocht te hebben om bv de sessionlimit te verhogen heb ik besloten om dit allemaal niet te doen. Zodoende kan ik het script overal inzetten zonder omgevingen aan te passen.Sending data to a remote command failed with the following error message: The total data received from the remote client exceeded allowed maximum. Allowed maximum is 524288000. For more information, see the about_Remote_Troubleshooting Help Topic
Na een nachtje slapen besloten om de boel eerst per server af te handelen en vervolgens een totaalstaatje te maken. Dat levert het volgende stukje op:
PowerShell:
1
2
3
4
5
| $servers=Get-Exchangeserver foreach ($server in $servers){ $mailboxsizes+=Get-MailboxStatistics -Server $server| Sort-Object TotalItemSize -Descending| Select-Object DisplayName,TotalItemSize -First 10 } $mailboxsizes = $mailboxsizes |Sort-Object TotalItemSize -Descending| Select-Object DisplayName,TotalItemSize -First 10 |
Voordeel was ook nog eens dat de verwerking een stuk sneller ging.
Eindresultaat is verwerkt in het EnvironmentReport script van Steve Goodman (aanrader wat mij betreft)
Renamen edb files
Ik kwam laatst een interessante case tegen.
Klant met meerdere Exchange servers in een DAG, meerdere databases per server en elke database een copy op een andere server. Bij het aanmaken van de databases een scriptfoutje gemaakt waardoor de namen van de files afwijken van de logische namen en erger nog, de namen gelijk waren aan elkaar.
Dat maakt het allemaal best verwarrend, vooral als je een edb wil mounten voor een restore.
Het rechttrekken hiervan zou best kunnen door een nieuwe DB aan te maken maar de logische naam was al goed. Komt nog bij dat de storage ook niet oneindig is natuurlijk en de databases niet al te klein zijn.
UIteindelijk door wat speurwerk en combineren van een aantal technet/blogs een procedure gemaakt waarbij je handmatig de edb-files hernoemd en je de passive copy niet hoeft te reseeden.
Enige nadeel hiervan is dat de databases waar het om gaat down gaat, je zal dus ergens downtime moeten claimen.
Voorbereidingen:
Er mogen geen lagged copies zijn. (waarde 0)
Get-MailboxDatabase | fl *lag*
Circulair Logging, moet op false gezet worden:
Controle: Get-mailboxdatase | fl *circ*
Aanpassen: Set-MailboxDatabase <database> -CircularLoggingEnabled $false
Daarna kijken of de status van de dbcopy ok is:
Get-MailboxDatabaseCopyStatus
Als alles healthy is dan:
Dismount-Database –identity <database>
Verwijder nu de databasecopy:
Remove-MailboxDatabaseCopy -Identity <database>\<server>
Hernoemen edb's
Controleer de fysieke paden waar de edb zich bevind en hou deze gelijk!
Hernoem de database:
move-DatabasePath -Identity EX03DB02 -configurationonly -EdbFilePath 'M:\EX03DB02\DB\EX03DB02.edb' -LogFolderPath 'M:\EX03DB02\Log'
Rename nu handmatig de edb-file van je "actieve" database
Ga naar de server waar de copy staat en rename de edb-file. Geef deze dezelfde naam als de actieve database.Daarna kunnen we de databasecopy weer aanmaken zonder een reseed.
En dan is het weer zaak de databases weer in de lucht te brengen.
Eerst de database mounten:
Mount database :Mount-Database -Identity <database>
Dan databasecopy aanmaken: Add-MailboxDatabaseCopy -Identity <database> -MailboxServer <server> -ActivationPreference '2'
Daarna op de server waar de copy aangemaakt is:
Net stop msftesql-Exchange
Net start MSExchangeSearch
Daarna circulair logging weer enablen:
Set-MailboxDatabase <database> -CircularLoggingEnabled $true
En klaar.
Bovenstaande gaat hier & daar kort door de bocht qua gebruikte commando's maar ik ga ervanuit dat je enigzins thuis bent in Exchange voordat je je hier aan waagt.
Klant met meerdere Exchange servers in een DAG, meerdere databases per server en elke database een copy op een andere server. Bij het aanmaken van de databases een scriptfoutje gemaakt waardoor de namen van de files afwijken van de logische namen en erger nog, de namen gelijk waren aan elkaar.
Dat maakt het allemaal best verwarrend, vooral als je een edb wil mounten voor een restore.
Het rechttrekken hiervan zou best kunnen door een nieuwe DB aan te maken maar de logische naam was al goed. Komt nog bij dat de storage ook niet oneindig is natuurlijk en de databases niet al te klein zijn.
UIteindelijk door wat speurwerk en combineren van een aantal technet/blogs een procedure gemaakt waarbij je handmatig de edb-files hernoemd en je de passive copy niet hoeft te reseeden.
Enige nadeel hiervan is dat de databases waar het om gaat down gaat, je zal dus ergens downtime moeten claimen.
Voorbereidingen:
Er mogen geen lagged copies zijn. (waarde 0)
Get-MailboxDatabase | fl *lag*
Circulair Logging, moet op false gezet worden:
Controle: Get-mailboxdatase | fl *circ*
Aanpassen: Set-MailboxDatabase <database> -CircularLoggingEnabled $false
Daarna kijken of de status van de dbcopy ok is:
Get-MailboxDatabaseCopyStatus
Als alles healthy is dan:
Dismount-Database –identity <database>
Verwijder nu de databasecopy:
Remove-MailboxDatabaseCopy -Identity <database>\<server>
Hernoemen edb's
Controleer de fysieke paden waar de edb zich bevind en hou deze gelijk!
Hernoem de database:
move-DatabasePath -Identity EX03DB02 -configurationonly -EdbFilePath 'M:\EX03DB02\DB\EX03DB02.edb' -LogFolderPath 'M:\EX03DB02\Log'
Rename nu handmatig de edb-file van je "actieve" database
Ga naar de server waar de copy staat en rename de edb-file. Geef deze dezelfde naam als de actieve database.Daarna kunnen we de databasecopy weer aanmaken zonder een reseed.
En dan is het weer zaak de databases weer in de lucht te brengen.
Eerst de database mounten:
Mount database :Mount-Database -Identity <database>
Dan databasecopy aanmaken: Add-MailboxDatabaseCopy -Identity <database> -MailboxServer <server> -ActivationPreference '2'
Daarna op de server waar de copy aangemaakt is:
Net stop msftesql-Exchange
Net start MSExchangeSearch
Daarna circulair logging weer enablen:
Set-MailboxDatabase <database> -CircularLoggingEnabled $true
En klaar.
Bovenstaande gaat hier & daar kort door de bocht qua gebruikte commando's maar ik ga ervanuit dat je enigzins thuis bent in Exchange voordat je je hier aan waagt.