Mailbox statistieken

Door Oogje op vrijdag 8 juli 2016 16:37 - Reacties (2)
CategorieŽn: Exchange, Powershell, Views: 2.068

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:

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:
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 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.

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

Door Oogje op dinsdag 9 juni 2015 14:26 - Reageren is niet meer mogelijk
Categorie: Exchange, Views: 2.589

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.

Exchange rechten op mailboxen

Door Oogje op dinsdag 21 april 2015 10:05 - Reacties (9)
Categorie: Powershell, Views: 3.509

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:

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?

Door Oogje op dinsdag 7 april 2015 20:32 - Reacties (2)
Categorie: vSphere, Views: 2.614

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.