Sunday, April 25, 2010

Outlook 2003 en Exchange 2010, kan dat en hoe zit dat met encryptie?

Wanneer ik met klanten over een implementatie van Exchange 2010 spreek, dan is een vaak gestelde vraag welke versies van Outlook ze kunnen gebruiken in combinatie met Exchange 2010. Het antwoord daarop is simpel: Outlook 2003 en hoger worden door Microsoft ondersteund in combinatie met Exchange 2010.  Natuurlijk mis je in Outlook 2003 handige features als MailTips en kun je het Personal Archive niet benaderen, maar alle basic functionaliteit werkt gewoon.

En toch lopen veel mensen tegen problemen aan wanneer ze met Outlook 2003 verbinding willen maken met een mailbox op Exchange 2010. De oorzaak daarvan is meestal encryptie. Exchange 2010 vereist namelijk dat MAPI/RPC verkeer tussen client en server versleuteld is, wanneer een client onversleuteld verbinding probeert te maken krijgt hij een foutmelding. Afhankelijk van het exacte scenario kunnen dat 9 verschillende foutmeldingen zijn, waaronder:

  • Kan uw standaardmappen voor e-mail niet openen. Kan het informatiearchief niet openen.
  • Kan Microsoft Outlook niet starten. Kan het Outlook-venster niet openen. Kan de set mappen niet openen. De server is niet beschikbaar. Neem contact op met de beheerder als deze situatie zich blijft voordoen.
  • Kan geen verbinding met de computer met Microsoft Exchange Server maken omdat er netwerkproblemen zijn opgetreden. Als dit probleem blijft bestaan, neemt u contact op met de systeembeheerder.

image

De 6 andere foutmeldingen zijn varianten op bovenstaande, het komt er op neer dat Outlook 2003 geen verbinding kan maken met de database. Daarnaast zie je bij clients die in Cached Mode draaien, dat de status rechts onder op Disconnected blijft staan.

In principe zijn er 2 oplossingen: Outlook aanpassen of Exchange. In het Outlook 2003 profiel kunnen we op het tabblad Security een vinkje zetten voor Encrypt data between…

image

Voor een enkele werkplek is het probleem hiermee opgelost, voor een gecentraliseerde oplossing voor alle werkplekken zul je dit liever met een GPO doen, in combinatie met de Office 2003 Administrative Templates.

Een minder fraaie oplossing is een aanpassing in Exchange 2010. De vereiste voor encryptie is een instelling op de Client Access server namelijk. Door die uit te schakelen kan ook een Outlook client verbinden welke geen gebruik maakt van versleuteling, maar dit gaat ten koste van het beveiligingsniveau van de oplossing. Je vindt deze property met de cmdlet Get-RpcClientAccess en kunt hem aan op uitschakelen met Set-RpcClientAccess:

Set-RpcClientAccess -Server <NaamServer> -EncryptionRequired $false

image 

Misschien ten overvloede, maar deze aanpassing is dus niet aanbevolen. Beter is het om de instelling van Outlook aan te passen, zodat de verbinding met Exchange 2010 versleuteld wordt.

Group Policy Objects bewerken met PowerShell

De uitdaging

Onlangs vroeg een klant mij advies over het configureren van het Outlook 2007 profiel op hun nieuw uit te rollen werkplekken. Nu is dit al redelijk eenvoudig doordat de nieuwe Exchange 2010 omgeving Autodiscover aanbiedt, maar de gebruiker wordt nog steeds geconfronteerd met een eenmalige wizard om Outlook te configureren. Ik zocht dus naar een oplossing die er voor zorgt dat Outlook deze wizard overslaat en Autodiscover gebruikt om een Outlook profiel te configureren.

Voorkennis: Voor dit artikel ga ik er van uit dat je bekend bent met de basics van het configureren van een Outlook profiel, dat je weet hoe Autodiscover in een Active Directory domein werkt en bekend bent met GPO’s.

Omdat mijn ervaring op dit gebied uit het 2003-tijdperk stamt, heb ik het volgende artikel gelezen om meer te weten te komen over het aanpassen van Outlook: Deploying additional registry values in the Office Customization Tool for Outlook 2007. Daar lees je over de ZeroConfigExchange key, als we deze in het register zetten en een waarde van 1 geven dan zal Outlook het gewenste gedrag vertonen. Om precies te zijn:

Key: HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\AutoDiscover
DWORD: ZeroConfigExchange
Values: 0 (or missing) = default autoconfiguration functionality
  1 = no interaction except for credentials prompt (if required)

De vraag is dan natuurlijk hoe we deze key op 1500 werkplekken in het register krijgen. Er zijn verschillende manieren om dit te doen, onder andere:

  1. Een opdrachtregel in het inlogscript, bijvoorbeeld: reg /s MijnKey.reg
  2. Een GPO en een custom ADM template schrijven
  3. Group Policy Preferences gebruiken
  4. Een 3rd party ‘workspace manager’ gebruiken
  5. Een GPO bewerken met PowerShell

Met PowerShell?

Deze klant heeft servers met Windows Server 2008 R2 en Windows 7 beheerwerkplekken, dus het ligt voor de hand om de nieuwe AD PowerShell functionaliteit te gaan gebruiken. Naast PowerShell, hebben we ook de GPMC Windows Feature nodig. Laten we deze eerst op ons systeem installeren. In PowerShell:

Import-Module ServerManager
Add-WindowsFeature GPMC

Met de eerste regel importeren we de PowerShell module ServerManager, dit is de PowerShell variant van de bekende beheertool die we voor het eerst in Windows Server 2008 zagen. Het resultaat is dat we een aantal nieuwe cmdlets beschikbaar krijgen in deze sessie, kijk maar eens met Get-Module ServerManager | fl welke dat zijn. In de tweede regel gebruiken we één van deze cmdlets om de Group Policy Management Console feature te installeren, die hebben we nodig om GPO’s te kunnen bewerken. Wanneer dit klaar is importeren we de GroupPolicy module in onze sessie:

Import-module GroupPolicy

Nu kunnen we de Set-GPRegistryValue cmdlet gebruiken om een registry value aan het een bestaande GPO toe te voegen. Hiervoor moeten we onder andere de naam van de GPO hebben, ik weet dat er iets van ‘user’ in de naam staat maar herinner me de naam niet precies. Daarom gebruik ik de Get-GPO cmdlet om de juiste naam te kunnen gebruiken:

Get-GPO -all | where { $_.displayname -like "*user*" }

Het resultaat:

DisplayName      : User Settings
DomainName       : domain.local
Owner            : DOMAIN\Domain Admins
Id               : aec2911a-cc51-427e-8b8a-767dbfef87d7
GpoStatus        : ComputerSettingsDisabled
Description      :
CreationTime     : 31-1-2010 13:42:19
ModificationTime : 25-4-2010 11:24:12
UserVersion      : AD Version: 51, SysVol Version: 51
ComputerVersion  : AD Version: 0, SysVol Version: 0
WmiFilter        :

Goed, nu we weten welke GPO we willen bewerken en weten wat de er in willen zetten kunnen we aan de daadwerkelijke opdracht beginnen. In plaats van een lange regel te typen, geef ik de voorkeur aan een klein scriptje waar in we met variabelen werken. Het is niet strikt noodzakelijk, maar maakt het wel heel gemakkelijk om je stukje code aan te passen of nog eens vaker te gebruiken. In de Technet Library heb ik de help-pagina opgezocht van de cmdlet: Set-GPRegistryValue. Daar lees ik over de parameters die nodig zijn om de registry key vaan de GPO toe te voegen. In het script begin ik met het vullen van deze variabelen:

$gpo = "User Settings"
$key = "HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\AutoDiscover"
$valuename = "ZeroConfigExchange"
$type = "Dword"
$value = 1

Vervolgens roep ik de cmdlet aan met de juiste parameters:

Set-GPRegistryValue -Name $gpo -Key $key -ValueName $valuename -Type $type -Value $value

Voor de duidelijkheid voeg ik nog wat commentaar toe en sla ik het scriptje op als BewerkGPO.ps1, dat ziet er uiteindelijk zo uit:

## Vul hier de juiste waardes in:
$gpo = "User Settings"
$key = "HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\AutoDiscover"
$valuename = "ZeroConfigExchange"
$type = "Dword" # Mogelijke waardes: {<Unknown> | <String> | <ExpandString> | <Binary> | <DWord> | <MultiString> | <QWord>}
$value = 1

## Importeer de GPMC module voor PowerShell
Import-module grouppolicy

## Voeg de key toe aan de GPO
Set-GPRegistryValue -Name $gpo -Key $key -ValueName $valuename -Type $type -Value $value

Het resultaat

En, zou het gelukt zijn? Helaas zijn deze cmdlets in bepaalde opzichten nog niet zo gebruiksvriendelijk als ervaren beheerders van Exchange misschien zouden verwachten. Sommige Get-cmdlets kennen bijvoorbeeld een –all parameter, anderen accepteren een wildcard en bij andere cmdlets moet je precies weten wat je zoekt. Om overzicht te krijgen is het misschien beter om een rapportje te laten genereren:

Get-GPO -all | where { $_.displayname -like "*user*" } | Get-GPOReport -ReportType html -Path c:\temp\report.html

In dit artikel hebben we gezien hoe we PowerShell kunnen gebruiken om met Group Policies te werken. Voor meer informatie over de gebruikte Group Policy cmdlets verwijs ik naar deze plek in de TechNet Library. Ter afsluiting nog een tip, verander 12.0 in de key door 14.0 om de key ook voor Outlook 2010 toe te voegen.

Wednesday, April 14, 2010

Exchange 2010 BPA: Unrecognized Exchange signature

Wanneer je de Exchange Best Practice Analyzer tool draait in een Exchange 2010 omgeving, dan kan de volgende fout gemeld worden:

image

"Unrecognized Exchange signature

Active Directory domain 'domainname' has an unrecognized Exchange signature. Current DomainPrep version: 12639."

De oorzaak hiervan is een bug in Exchange, dit ligt niet aan je omgeving. Een oplossing zit in SP1 voor Exchange 2010 ingebakken, maar zal vermoedelijk ook in Rollup Pack 4 voor Exchange 2010 worden opgenomen. Beiden zijn nog niet uit, nog even wachten dus.