![[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.
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.
Exchange rechten op mailboxen
Laat ik beginnen met het feit dat ik een Powershell beginneling ben die een beetje aanrommelt om het dagelijkse leven als sysadmin wat aangenamer te maken.
Onderstaande script heb ik gemaakt om snel op een aantal mailboxen de send as/send on behalf en full mailbox access uit te kunnen lezen.
Voor versie 2 staat het netter maken van de output en het omzetten van de loginnaam naar de displaynaam op het programma.
Mocht iemand daar al wat voor hebben houd ik me natuurlijk ook aanbevolen
Onderstaande code opslaan in een Powershell bestand en aanroepen vanaf de PS-prompt. Daarbij aangeven welke csv er gebruikt moet worden, bv .\script.PS1 .\input.csv
Opzet van de CSV is vrij eenvoudig:
De ps-code:
Onderstaande script heb ik gemaakt om snel op een aantal mailboxen de send as/send on behalf en full mailbox access uit te kunnen lezen.
Voor versie 2 staat het netter maken van de output en het omzetten van de loginnaam naar de displaynaam op het programma.
Mocht iemand daar al wat voor hebben houd ik me natuurlijk ook aanbevolen
Onderstaande code opslaan in een Powershell bestand en aanroepen vanaf de PS-prompt. Daarbij aangeven welke csv er gebruikt moet worden, bv .\script.PS1 .\input.csv
Opzet van de CSV is vrij eenvoudig:
code:
1
2
3
4
| Mailbox mailbox1@domein.nl mailbox2@domein.nl mailbox3@domein.nl |
De ps-code:
PowerShell:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| param( [string]$file ) import-csv $file | ForEach { $SendAs = Get-mailbox $_.Mailbox |Get-ADPermission | ? {$_.ExtendedRights -like "Send-As" -and $_.User -notlike "NT AUTHORITY\SELF" -and !$_.IsInherited} | select user |fl $FullAccess = Get-MailboxPermission $_.Mailbox | ? {$_.AccessRights -eq "FullAccess" -and !$_.IsInherited} | select user |fl $SendOnBehalf = Get-mailbox $_.Mailbox | select -ExpandProperty GrantSendOnBehalfTo | select name |fl Echo "Mailbox:" $_.Mailbox Echo "Send As:" $SendAs Echo "Full Access:" $FullAccess Echo "Send on Behalf:" $SendOnBehalf } |
VDP bug?
Gelukkig niet vaak nodig, maar vandaag bij een klant moest er toch een restore komen op file niveau.
Inloggen op de vSphere Data Protection Restore Client website wou echter niet lukken met de Local Credentials.
Het uitspitten van de space\avamar\var\flr\server_logs\flr-server.log bracht niet veel duidelijkheid.
"Unable to browse destination client because: Authentication failure or insufficient permissions in guest operating system. Retrying..." was nou ook niet echt verhelderend.
Omdat de klant automatisch een rename van Administrator accounts doet de local admin maar weer hernoemd naar Administrator en voila, het probleem was over en file restore werkt weer.
Een nieuw Administrator-account aanmaken werkte trouwens niet.
Inloggen op de vSphere Data Protection Restore Client website wou echter niet lukken met de Local Credentials.
Het uitspitten van de space\avamar\var\flr\server_logs\flr-server.log bracht niet veel duidelijkheid.
"Unable to browse destination client because: Authentication failure or insufficient permissions in guest operating system. Retrying..." was nou ook niet echt verhelderend.
Omdat de klant automatisch een rename van Administrator accounts doet de local admin maar weer hernoemd naar Administrator en voila, het probleem was over en file restore werkt weer.
Een nieuw Administrator-account aanmaken werkte trouwens niet.