dinsdag 22 april 2014

Nieuwe versie Azure/Office 365 DirSync: 6765.0006

Versie 6765.0006 van de Microsoft Azure/Office 365 Directory Sync tool is uitgebracht. De laatste versie heeft net als de vorige release een aantal bugfixes die te maken hebben met de Password Sync feature. Download de laatste versie hier: Windows Azure Active Directory Sync tool – 64 bit

Meer informatie over de laatste en voorgaande versies kun je lezen in de TechNet Wiki pagina: Microsoft Azure Active Directory Sync tool - Version Release History

dinsdag 15 april 2014

Public Folders migreren naar Exchange 2013? Typo in MS script

Op http://technet.microsoft.com/en-us/library/jj150486(v=exchg.150).aspx vind je in stap 4 een kort script om meerdere Public Folder mailboxen aan te maken. Hierin staat een typefout:

$numberOfMailboxes = 25; 
for($index =1 ; $index -le $numberOfMailboxes ; $index++)
{
$PFMailboxName = "Mailbox"+$index; if($index -eq 1) {New-Mailbox -PublicFolder $PFMailboxName -HoldForMigration:$true -IsExcludedFromServingHiearchy:$true;}else{New-Mailbox -PublicFolder $PFMailboxName -IsExcludedFromServingHierarchy:$true}
}


In het vet gedrukte woord mist een r, dit moet zijn: IsExcludedFromServingHierarchy. Let hier even op dat je dit aanpast voordat je het script draait. Te laat? Zet de property dan gewoon zelf goed met Set-Mailbox –IsExcludedFromServingHierarchy.

Export-PublicFolderStatistics.ps1 en Parameter declarations are…

Bij een Public Folder migratie van Exchange 2007 naar Exchange 2013 of Exchange Online moet je het script Export-PublicFolderStatistics.ps1 uitvoeren op Exchange 2007. Hierbij kun je tegen de volgende foutmelding aanlopen:

[PS] C:\Program Files\Microsoft\Exchange Server\Scripts>.\Export-PublicFolderStatistics.ps1 "C:\PFMigration\folder2mapsize.csv"  Ex2007.domain.local
Parameter declarations are a comma-separated list of variable names with optional initializer expressions.
At C:\Program Files\Microsoft\Exchange Server\Scripts\Export-PublicFolderStatistics.ps1:16 char:168
+         HelpMessage = "Full path of the output file to be generated. If only filename is specified, then the output file will be generated in the current directory.")] <<<<

Deze fout kan voorkomen als je PowerShell 1.0 op de server hebt, om dit script uit te voeren is minimaal PowerShell 2.0 nodig. Download deze hier: http://support.microsoft.com/kb/968929/nl

woensdag 26 maart 2014

Dynamische Distributielijst voor alle mailboxen in een database

In oude versies van Exchange was het gebruikelijk om een aantal specifieke instellingen, zoals bijvoorbeeld mailboxquota, in te stellen per database. Bij moderne versies van Exchange kunnen we veel instellingen configureren aan de hand van policies of slimme PowerShell scripts. Tegenwoordig hebben we ‘online mailbox moves’ en is het uitvoeren van een offline defragmentatie vervangen door het moven van de mailboxen naar een nieuwe database.

Databases zijn dus niet meer zo statisch als ze voorheen waren. Toch kwam ik een vraag tegen van een beheerder die zich afvroeg of hij een Dynamische Distributielijst (DDG) kon maken waarmee hij mail kon sturen naar alle mailboxen in een database, in dit geval op Exchange 2007.

image

Bij het aanmaken van een DDG kun je gebruik maken van een aantal standaard parameters, zoals bijvoorbeeld Organization Unit, Company, Department of Custom Attribute. Maar je kunt ook een eigen Recipient Filter opstellen, en daarmee kunnen we in dit geval dus filteren op de Database-eigenschap.

De Help-pagina van New-DynamicDistributionGroup geeft uitgebreide uitleg en een paar voorbeelden. Als we het voorbeeld met de –RecipientFilter een beetje aanpassen dan kunnen we het doel van de vraagsteller bereiken:

New-DynamicDistributionGroup -Name "Mailbox Users in DB01" -RecipientFilter {((RecipientType -eq 'UserMailbox' -and Database -eq 'Server01\DB01') -and -not(Name -like 'SystemMailbox{*'))}

Het gaat in dit geval om Exchange 2007 dus de database moeten we aanspreken als server\database, of eventueel de CN of GUID. Bij Exchange 2010 en 2013 kunnen we volstaan met alleen de naam van de database.

vrijdag 21 maart 2014

De zin en onzin van het archiveren van Exchange

Exchange en archivering, het blijft een interessant onderwerp. We spreken regelmatig klanten die de data in Exchange archiveren met een 3rd party oplossing en de kosten van licenties, onderhoud, upgrades van deze oplossingen niet langer kunnen rechtvaardigen. De oplossing moet bovendien naadloos inhaken in Exchange om de gebruiker altijd toegang te geven tot zowel de actuele als oudere data, ook als er gezocht wordt of als het gaat om toegang via smartphone of tablet. Andere organisaties worden zich opeens bewust van de wet- en regelgeving waar ze aan moeten voldoen en gaan voor het eerst onderzoeken hoe ze dit het beste in kunnen vullen.

ICT detacheerder Peak-IT schreef hier onlangs een artikeltje over: http://www.peak-it.nl/archiveren-van-exchange/ en deelde deze in de ICT Professionals & Opdrachtgevers groep op LinkedIn. Hieronder plaats ik mijn reactie nog een keer:

Leuk artikeltje, heel goed om te starten met de waarom-vraag. Alleen als je het waarom weet dan kun je een passende oplossing kiezen, of na een goed gesprek besluiten om het niet te gaan doen.

Ik zie alleen één veel voorkomend misverstand in het artikel: "Bewaren van email is dus verplicht en verstandig. Maar met een standaard Exchange-server is dat niet te doen. De opgehoopte, nooit gebruikte email gaat dan een onevenredige druk leggen op die Exchange-server. Gaan we dan toch ‘opschonen’? Met de gigabytes van het bewuste quotum? "

De tijd dat Exchange om technische en performance-redenen niet met grote hoeveelheden data om kon gaan ligt al lang achter ons. Het aantal IOPs is zover gedaald dat je terug kunt naar goedkope storage met disks van 1, 2 of zelfs 4 TB per stuk. Mailboxen van 50-100 GB groot zijn dan ook zeer goed mogelijk, dat is dus heel andere koek dan die enkele gigabytes van vroeger toen een SCSI harddisk nog 36 GB groot was en je niet meer dan enkele duizenden items in je Outlook mappen mocht hebben.

3326092093_d6d6bd06f1

Dus de performance van Exchange hoeft het probleem niet te zijn, maar wat dan wel? Dan kom je terug bij de waarom-vraag waarmee ik net begon. Als klant zijn gebruikers simpelweg de mogelijkheid wil bieden om e-mail onbeperkt te kunnen bewaren dan zijn we er al met een goed ontworpen Exchange-omgeving. Want alle data gewoon waar hij hoort: in de mailbox. Als klant met Outlook in cached-mode werkt en de grootte van de lokaal opgeslagen kopie wil beperken dan kan dat met Outlook 2013's 'cache slider' of met Exchange's ingebouwde In-Place Archiving, eerder bekend als Online Archive of Personal Archive. Hoewel die laatste optie een Enterprise CAL vereist is het met deze twee oplossingen niet nodig om te investeren in een separate archiveringsoplossing.

Wanneer klant wil archiveren om te voldoen aan wet- en regelgeving dan wordt het al snel andere koek. Doorgaans vereisen die zaken als 'roque administrator protection' en andere features die Exchange zelf niet bevat. En het zijn juist die eisen die je helder moet krijgen om een passende oplossing aan te kunnen bieden.

Dus archiveren doe je anno 2014 om functionele eisen en niet om reden van performance.

Dat laatste kan ik niet vaak genoeg herhalen. Archiveren want dan kan die data naar goedkope storage? Bereken maar eens hoeveel IOPs we nodig hebben en zet dan direct alle Exchange-data op goedkope storage. Archiveren want dan houden we de mailbox database lekker kleine? Maak die business-case nog eens een keer, en welk probleem lossen we hier ook alweer precies op?

In alle gevallen begint het dus met de vraag: waarom archiveren? En die waarom-vraag moeten ICT dienstverleners steeds blijven stellen. Beluister wat de verwachting van klant eigenlijk is en toets deze. Alleen dan kun je een echt passende oplossing bieden.

donderdag 20 maart 2014

Waarom PowerShell beter is dan sh, bash, ksh en csh.

Heel, heel lang geleden hadden computers nog geen eenvoudige manier om commando’s in te geven. Eind jaren zestig, begin jaren zeventig doet de ‘Shell’ zijn intrede. Een shell is een manier om commando’s in te geven buiten de kernel. Veel van de huidige computergebruikers denken dan aan MS-DOS maar de shell heeft daarvoor al een ruime historie in de wereld van Unix en zijn voorlopers.

In 2003 kondigde Microsoft een nieuwe shell aan, eerst heette die nog Monad en pas later hebben we kennis gemaakt met PowerShell. Inmiddels zijn commando’s als netstat.exe, ipconfig.exe en dnscmd.exe achterhaald en vervangen door cmdlets als Get-NetTCPConnections, Get-NetIPAddress en Add-DnsServerResourceRecordCName.

PowerShell commando’s hebben een consistente opbouw en beginnen altijd met een werkwoord (*) gevolgd door een zelfstandig naamwoord. Met Get-Mailbox vraag je informatie op, met Set-Mailbox stel je iets in en Remove-Mailbox verwijder je de mailbox. Gaat het om een certificaat, gebruiker, registry key, directory, een ACL of wat voor ander object dan ook? De opbouw van de cmdlets is altijd gelijk. Vergelijk dat eens met Unix commando’s als fc, man, pwd en bg.

Maar wat nog veel belangrijker is, met PowerShell werken we met objecten en Unix werkt met tekst. Het volgende voorbeeld gebruik ik graag om het verschil uit te leggen. Stel dat we het aantal bestanden willen tellen in een directory. Met Unix kunnen we dat doen door de uitvoer van ls (list) met de l optie (lijst met informatie) door te voeren aan wc (word count) met de l optie (lines). Het commando ziet er dan zo uit:

ls –l | wc –l

image

De uitkomst is 5, toch best verrassend aangezien er maar vier bestanden staan. De verklaring is dat de output van ls –l bestaat uit vijf regels tekst, de bovenste regel geeft namelijk het totale aantal ‘blocks’ weer. Voor het echte antwoord moeten we er dus eigenlijk 1 afhalen.

Met Unix en ook Linux werken we dus met tekst. Het ene commando geeft tekst als output, met een volgend commando kunnen we deze tekst verder verwerken. Als we data uit de tekst willen halen dan moeten we die parsen met tools als awk of sed waarmee we dus de regel ‘totaal 0’ uit het resultaat hadden kunnen filteren.

In PowerShell doen we nu hetzelfde. We vragen de items op in de huidige directory met Get-ChildItem (ik had ook één van de aliassen als dir of ls kunnen gebruiken) en de uitvoer van dit cmdlet voeren we door aan Measure-Object.

Get-ChildItem | Measure-Object

image

De uitkomst is hier 4, het correcte antwoord dus. De reden hiervan is dat PowerShell werkt met objecten, niet met ‘domme’ tekst. Weliswaar wordt de output van Get-ChildItem op het scherm weergegeven op vergelijkbare wijze als het DOS commando dir of ls in Unix maar dat is domweg de standaard output naar scherm. Als ik de output doorvoer naar Measure-Object dan zien we dat deze niet de 10 of 11 regels tekst meet maar de vier objecten die Get-ChildItem gevonden heeft in de huidige directory.

Met deze eenvoudige demo hebben we dus het verschil tussen tekst en objecten gezien. Shells als MS-DOS, Unix en Linux werken met tekst die je kunt parsen om er iets zinvols mee te doen. PowerShell werkt met objecten waar je direct slimme dingen mee kunt doen.

(*) Beginnen PowerShell cmdlets altijd met een werkwoord?

woensdag 19 maart 2014

Eerste aankondigen van Exchange 2013 CU5 nu al te zien

Voor wie het even gemist had… Exchange 2013 krijgt ongeveer elk kwartaal een ingrijpende upgrade die nu Cumulative Update (CU) genoemd is. Technisch gezien lijkt dit sterk op een Service Pack, zo wordt tijdens de installatie van een CU heel Exchange verwijderd en opnieuw geïnstalleerd en is er geen manier om deze ongedaan te maken. Dus net als een Service Pack. En dan komt er één keer per jaar een Service Pack uit, die zoals gezegd dus sterk op een CU lijkt.

Microsoft heeft het plan van een CU per kwartaal niet gehaald, in het eerste jaar zijn CU1, CU2 en CU3 uitgebracht en zeer recent dus SP1. In de aankondiging van SP1 nam Microsoft al een voorschot op de volgende update en kondigde de nieuwe naam aan:

Our next update for Exchange 2013 will be released as Exchange 2013 Cumulative Update 5. This CU release will continue the Exchange Server 2013 release process.

In volgorde ziet dat er dus zo uit:

image

Wanneer je nu verantwoordelijk bent voor het beheer van een omgeving met Exchange 2013 CU3 en niet dagelijks alle blogs en Twitterfeeds volgt dan kan het dus zijn dat je op zoek gaat naar Cumulative Update 4 welke dus niet bestaat. Persoonlijk vind ik deze keuze wat ongelukkig, liever had ik gezien dat er doorgenummerd was of dat SP1 opgevolgd was door CU1 voor SP1.

En inmiddels zijn de eerste artikelen op Technet verschenen die melding maken van CU5. De eerste was natuurlijk het artikel met de bug met 3rd party Transport Agents die al snel na SP1 uit kwam. Maar er zijn er al meer:

Er is nog niet aangekondigd wanneer CU5 beschikbaar komt.

Connecties tellen (netstat) maar dan met PowerShell

Als je informatie zoekt over de sessies die een server open heeft staan dan doe je dit doorgaans met netstat –ano. Als je vervolgens iets zinvols wilt doen met de lange lijst aan regels kun je filteren op een poortnummer of IP-adres:

netstat –ano | findstr :443

De output van netstat is tekst dus om er meer mee te doen moeten we deze eerst ‘parsen’ en in bruikbare variabeles stoppen. Veel PowerShell-scripts doen dit dan ook, ze verwerken de tekst en zoeken naar patronen in de tekst om deze te kunnen filteren of sorteren.

Gelukkig kan het sinds Server 2012 ook met een native PowerShell commando: Get-NetTCPConnection. Dit commando geeft een output naar scherm die vergelijkbaar is met die van netstat. Het verschil is natuurlijk dat het niet om een statische view gaat maar dat we hier met objecten werken. Filteren, sorteren en wat al niet meer kan nu dus op de PowerShell manier.

Een paar voorbeelden:

Get-NetTCPConnection -RemotePort 444

Get-NetTCPConnection -LocalPort 443 | sort RemoteAddress

Get-NetTCPConnection -State Established | measure

image

Ik hoop dat je hiermee uit de voeten kunt, de rest wijst eigenlijk voor zich. Meer informatie kun je vinden in de Technet Library of natuurlijk met Get-Help Get-NetTCPConnection –Full.

dinsdag 18 maart 2014

Onder de motorkap kijken bij Exchange installaties

Het installeren van Exchange Server, een Service Pack of Cumulative Update duurt al snel een uur of meer. In die tussentijd zit er vaak niets anders op dan rustig afwachten en ondertussen op het scherm zien dat Exchange bezig is aan stap 4 van de 16… Zou het niet mooi zijn als je realtime kon volgen wat er op dat moment allemaal gebeurt?

Of het nu gaat om een nieuwe installatie of een upgrade, Exchange Setup schrijft alle acties en ook eventuele foutmeldingen weg in een bestand ExchangeSetupLog.log in de directory C:\ExchangeSetupLogs. Dit logbestand kun je tijdens de installatie openen om te bekijken wat op dat moment de laatste status is.

BareTail

In de UNIX-wereld gebruiken we tail –f om de laatste regels van een bestand realtime te kunnen volgen. Op een Windows-systeem gebruik ik hiervoor de gratis versie van Baretail:

image

Op deze manier kun je tijdens de installatie steeds een oogje houden op het verloop van de installatie. In de praktijk zie je wel eens dat het proces stil lijkt te staan omdat een service niet gestopt kan worden en Exchange Setup steeds 30 seconden wacht voordat hij het opnieuw probeert. Als je dit ziet dan kun je vals spelen door het proces handmatig te sluiten in Task Manager.

PowerShell

Tegenwoordig kan dit ook met PowerShell, het Get-Content cmdlet heeft hiervoor de –Wait parameter:

Get-Content -Path C:\ExchangeSetupLogs\ExchangeSetup.log –Wait

Waarom?

Op deze manier kun je tijdens de installatie steeds een oogje houden op het verloop van de installatie. In de praktijk zie je wel eens dat het proces stil lijkt te staan omdat een service niet gestopt kan worden en Exchange Setup steeds 30 seconden wacht voordat hij het opnieuw probeert. Als je dit ziet dan kun je vals spelen door het proces handmatig te sluiten in Task Manager.

woensdag 12 maart 2014

IMAP4 of POP3 inschakelen op Exchange 2013

De protocollen IMAP4 en POP3 bieden ten opzichte van MAPI, het native Outlook-Exchange protocol, bar weinig functionaliteit. Ook worden ze vaak verkeerd gebruikt waardoor gebruikersnaam en wachtwoord onversleuteld over het netwerk gaan en makkelijk afgeluisterd kunnen worden. Sinds Exchange 2007 zijn deze protocollen standaard dan ook niet meer aanwezig op een Exchange-server.

De procedure om deze op Exchange 2013 in te schakelen wijkt een beetje af van die op Exchange 2007 en 2010. Wat gelijk blijft is dat we de service moeten starten en hem configureren om dit automatisch te doen bij het booten van de server. Wat verschilt is dat het nu om een service op de Client Access rol gaat en ook eentje op de Mailbox rol.

Inschakelen van IMAP4 op de Client Access rol:

Set-Service msExchangeIMAP4 -StartupType automatic
Start-Service msExchangeIMAP4

Hetzelfde maar dan op de Mailbox rol:

Set-Service msExchangeIMAP4BE -StartupType automatic
Start-Service msExchangeIMAP4BE

En dus op een server met zowel de Client Access als de Mailbox rol:

Set-Service msExchangeIMAP4 -StartupType automatic
Start-Service msExchangeIMAP4
Set-Service msExchangeIMAP4BE -StartupType automatic
Start-Service msExchangeIMAP4BE

Voor POP3 is de procedure identiek, alleen heten de services dan msExchangePOP3 en msExchangePOP3BE.

De standaardconfiguratie vereist voor zowel POP3 als IMAP4 dat TLS gebruikt wordt. Voor applicaties die dit niet ondersteunen kan het soms nodig zijn om deze instelling aan te passen, je vindt deze in EAC onder de eigenschappen van de server:

image

Of gebruik de Set-POPSettings en Set-IMAPSettings cmdlets met de –LoginType PlainTextLogin parameter. In beide gevallen wordt de nieuwe instelling pas actief na het opnieuw starten van alle POP3 of IMAP4 services.