Potřeboval jsem dostat počet mailboxů na jednotlivých Exchange serverech v celé Exchange organizaci, přičemž na některém serveru je více mailbox databází, na některém pouze jedna. Správný skript jsem našel zde, jen jsem jej trochu upravil k tomu, co potřebuji.
Set-AdServerSettings -ViewEntireForest $true –PreferredGlobalCatalog dc.metro.tld
$exchservers = Get-Exchangeserver
foreach($exchserver in $Exchservers)
{
get-mailbox -Server $exchserver.name | Group-Object Database | Select-object Count,Name
$exchserver.name
}
V předchozím příspěvku jsem detekoval nepoužívané mailboxy, zde vylezou celkové. Takže používané = celkové – nepoužívané.
Našel jsem zajímavý skript na detekci neaktivních mailboxů. Často se totiž potkávám s tím, že datum posledního přístupu ke schránce nejde použít, buď kvůli antivirovému nebo zálohovacímu systému, které toto datum změní. Výše uvedený skript však na to jde jinak – kontroluje nejnovější položku v Odeslané poště.
Zprovoznění skriptu ale není úplně triviální. Pokud skript umístím např. do C:\bat\, tak je pak nutné v PowerShellu spustit toto:
. c:\bat\InActiveMBX.ps1 (opravdu je před cestou tečka následovaná mezerou)
Get-InActiveMailbox
Z dostupných přepínačů používám –Server nebo –Database a poté –Idledays. Z prvních dvou uvedených se smí použít vždy jen jeden.
Testovací spouštění mi pořád dávalo naprosto nesmyslná čísla v počtu neaktivních uživatelů ve třech mailbox databázích a vůbec to nebralo v potaz další tři mailbox databáze. No strávil jsem nad tím dlouhou dobu, abych nakonec zjistil, že jsem zase narazil na default nastavení PowerShellu, na kterých jsem si vylámal zuby už asi před půl rokem, akorát jsem si to tenkrát nenapsal.
Pokud mám forest s hromadou domén a chci, aby se Exchange příkazy týkaly i jiných objektů z ostatních domén (tj. nejen z té domény, kde je umístěn Exchange server), tak je třeba na začátku PowerShell skriptu spustit toto:
Set-AdServerSettings -ViewEntireForest $true –PreferredGlobalCatalog dc.domain.tld
Teprve poté mi skript začal dávat správné výsledky, protože uživatelé Exchange serveru ve forest root doméně jsou i v jiných doménách.
Přestávám chápat, co všechno může Microsoft po…t. Jak jsem psal včera, objevil jsem se zpožděním CU3, který by měl opravovat OWA Premium rozhraní pro IE 11. Tak jsem si říkal, paráda, nainstaluji a bude pokoj. Nakonec z toho byl dvouhodinový výpadek a totální deziluze.
Vše začalo touto chybovou hláškou při prvním pokusu o instalaci CU3:
Error:
Unable to remove product with code 4934d1ea-be46-48b1-8847-f1af20e892c1. Fatal error during installation. Error code is 1603. Last error reported by the MSI package is 'Unable to install because a previous Interim Update for Exchange Server 2013 Cumulative Update 1 has been installed. Please use Add/Remove Programs to uninstall the Interim Update before running this setup again.'.
Říkám si, něco podobného tady už bylo, tak to zkusíme znovu. Ouvej, stejný konec. No jo, jenže Exchange nefunguje. No, tohle už tady taky bylo – kouknu na služby – a vskutku všechny Disabled. Tak jo, tak já teda ten hotfix odinstaluju. Koukám do Uninstall program, View installed updates a pod Exchange 2013 CU1 vidím jeden jediný Security hotfix.
To by mne čert vzal, vždyť podle komentáře u tohoto článku by nemělo být nutné Security hotfixy z předchozího CU odinstalovávat a tohle by se nemělo vůbec stát! Více...
Tohle mi nějak uteklo. Již na konci listopadu (konkrétně 25.11.) vydal Microsoft Update Rollup 3 pro Exchange Server 2010 SP3 a zároveň Cumulative Update pro Exchange 2013. V popisu balíku pro Exchange 2010 je napsáno, že neobsahuje výrazný kritický hotfix. U balíku pro Exchange 2013 je to už jinak, obsahuje opravu potenciálního problému se zálohou Exchange dat, která by za jistých podmínek nemusela jít obnovit. A taková záloha je … censored.
Nicméně proč o tom píšu – oba dva balíky obsahují nápravu chyby, která mne neuvěřitelně vytáčela. Internet Explorer 11 totiž v identifikaci prohlížeče přestal používat řetězec “MSIE”. A co se nestalo? Produkty té samé firmy s tím nepočítaly, takže uživatelé IE 11 nemohli používat OWA Premium rozhraní, pokud si nezařadili konkrétní stránku do Compatibility View seznamu (který se mimochodem v IE 11 přestěhoval naprosto hloupě).
Oprava je na světě, tak jdu instalovat.
Obrátil se na mne kolega z Francie se zajímavým požadavkem – jak nastavit Exchange, aby každý nově založený uživatel měl zakázány protokoly IMAP4 a POP3. Nastavení protokolů na již existujících schránkách je jasné a známé, ale jak to nastavit “by-default”? Nakonec jsem zapátral a našel částečné řešení na této stránce. Více...
V předchozím článku jsem se zabýval vzájemných ověřením (Mutual Authentication) mezi Exchange serverem a Outlookem. Když jsem se pídil po dostupných informacích, narazil jsem na příkazy ovlivňující nastavení preferencí chování Outlook na rychlých a pomalých sítích. Více...
Včera jsem se zase dostal k zamotané záležitosti. Firma má pobočku v Čechách a na Slovensku, tj. dvě AD sajty propojené VPN. V české sajtě je jeden Exchange Server 2010 s HT, CAS a MBX rolí. Na Slovensku byl Exchange 2003, který byl nedávno nahrazen taktéž Exchange Serverem 2010 s HT, CAS a MBX rolí. A od té doby začaly záhadné problémy slovenských uživatelů, kterým se rekonfigurovaly Outlooky, objevovalo se hlášení, že název certifikátu neodpovídá názvu serveru proxy atd. Více...
To je zase dílo. Před časem jsem nějak naprosto bez problémů nastavil Outlook 2013 pro synchronizaci s pokusně vytvořeným Outlook.com účtem. Fungovalo. Pak jsem dal notebook do domény a potřeboval jsem vytvořit všechny Outlook profily znovu. A nastavení synchronizace na Outlook.com mi nešlo ani zaboha. Začal jsem lovit na netu, přeci nemůžu být jediný s tímto problémem. Nejsem. Více...
Tak jsem se dnes taky potkal s nefunkčním Exchange ActiveSync protokolem u některých uživatelů při upgrade z Exchange Serveru 2003 na Exchange Server 2010. Naštěstí je to chyba častá a tím pádem dobře zdokumentovaná, třeba zde nebo zde. Více...
Řešil jsem dnes záhadnou stížnost na nedoručení pošty u Exchange 2003. Dohledal jsem, že mail měl být doručen lokálně na back-end serveru – a vzápětí bylo odesláno NDR. V tu samou dobu bylo do Eventlogu zapsáno ID 3030 od MSExchangeTransport a v Description bylo uvedeno, že se jedná o status code 5.6.3. Poté, co jsem si našel tabulku s kódy, jsem zjistil, že se cílový server bránil příjmu e-mailu s více než 250-ti přílohami. Více...