Wednesday, November 11, 2009

Exchange 2010: Handtekening op basis van AD informatie

Exchange 2007 bracht ons transport rules, met transport rule konden we heel gemakkelijk een disclaimer plaatsen onder bijvoorbeeld alle uitgaande berichten. Voor veel klanten was een transport rule voor dit doel de eerste en vaak ook de enige rule die ze aanmaakten. Maar naast het toevoegen van een juridische boodschap kunnen we natuurlijk ook ieder uitgaand bericht voorzien van de zelfde ondertekening. Een veel gestelde vraag was of we hier ook dynamische gegevens in konden opnemen en dat was helaas niet mogelijk. Exchange 2010 brengt daar verandering in en in dit artikel laat ik zie hoe eenvoudig het is om dit in te stellen.

Het maken van een transport rule in Exchange 2010 gaat precies het zelfde als in Exchange 2007: in de Exchange Managemens Shell met de New-TransportRule cmdlet of in de Exchange Management Console. In dit artikel kies ik de EMC om een disclaimer toe te voegen die dus geen juridische tekst bevat maar een gepersonaliseerde handtekening, de gegevens hiervoor halen we uit Active Directory.

Om te beginnen openen we de EMC en browsen we naar Organization Configuration, Hub Transport. In het rechterpaneel kiezen we New Transport Rule… en de volgende wizard wordt voor ons gestart:

1

Geef de transport rule een naam en indien gewenst een commentaar, een nieuwe transport rule is standaard gelijk Enabled, haal het vinkje weg als je dat nog niet wilt en klik op Next.

2

Een transport rule bestaat uit 3 componenten: een voorwaarde, een aktie en een uitzondering. In mijn voorbeeld heb ik als Condition gekozen voor mail die verzonden wordt door gebruikers van mijn organisatie, naar mensen buiten mijn organisatie. Klik op Next.

3

De actie is duidelijk hier, we willen een disclaimer toevoegen. Wanneer we dit vinkje gezet hebben kunnen we in het onderste deel van de wizard klikken op ‘disclaimer text’.

4

Zoals je ziet kunnen we hier HTML-tags gebruiken, in dit voorbeeld heb ik alleen een h3-tag gebruikt maar je kunt ook denken aan een specifiek lettertype of een link naar het bedrijfslogo. Verder kunnen we hier dus met variabelen uit Active Directory werken, we zetten de naam van de variabel simpelweg tussen %%. In de praktijk zul je hier misschien nog een hr-tag en daaronder je disclaimer-text aan toe willen voegen. Klik op OK en druk op Next.

6

In dit voorbeeld heb ik geen Exception gekozen en klikken we op Next.

7

Hier kunnen we onze keuzes nog een keer controleren en bevestigen we ze met een klik op New.

8

En zoals we inmiddels van Exchange gewoon zijn krijgen we hier te zien dat de opdracht met succes is uitgevoerd en welke PowerShell regel er onder de motorkap voor ons is uitgevoerd. Klaar is Kees!

Maar hoe ziet het eindresultaat er nu uit? Minder spectaculair dan je misschien zou verwachten:

11

Dan nog even terug naar de AD properties die we gebruikt hebben in onze handtekening, je vraagt je misschien af welke properties je daar kunt kiezen en welke naam je precies aan moet houden. Daar is een handig truukje voor. Hiertoe openen we de eigenschappen van een mailbox en passen we de gewenste velden aan, bijvoorbeeld door een leeg veld met een waarde te vullen of een ingevuld veld met één karakter aan te passen, zoals ik hier gedaan heb.

9

Zodra we de eerste aanpassing doen wordt er een button klikbaar die daarvoor nog greyed out was. Dit is een nieuwe functie van Exchange 2010, dit is de ‘Show Exchange Management Shell command’ button. Wanneer we hier op klikken krijgen we de PowerShell regel te zien welke uitgevoerd wordt wanneer we de wijzigingen bevestigen door op OK te klikken, vergelijkbaar met de terugkoppeling die we op de laatste pagina van de wizard zagen.

10

Hier zien we de parameters van de Set-Mailbox cmdlet die gewijzigd zouden worden: StreetAddress, City en Department, dit zijn de namen die we hierboven gebruikt hebben. Speel maar eens met de velden die voor jou interessant zijn, op deze manier vind je snel welke namen je zoal kunt gebruiken.

Met dit eenvoudige voorbeeld hoop ik jullie fantasie geprikkeld te hebben, ik weet zeker dat jullie een slimmere of nettere toepassing van deze functionaliteit weten te bedenken. Succes!

Thursday, November 5, 2009

EMS: Exchange 2003 beheren met Windows 7

Ondanks de enorme verbeteringen van Exchange 2007 en 2010 is de meest in het wild voorkomende versie nog steeds Exchange 2003. Het is dan ook niet raar dat veel mensen hun Exchange 2003 server willen beheren vanaf een Windows 7 computer door hier de Exchange System Manager (ESM) op te installeren. Helaas is er geen ESM voor Windows 7 en de vraag is of die er überhaupt komen gaat. Hoe dan wel?

De laatste versie van ESM is medio 2008 uitgebracht voor Windows Vista, hier te downloaden. Wanneer je deze download en opstart dan word er een directory ESMVISTA aangemaakt met daarin een bestand met de naam ESMVISTA.MSI.

image

Wanneer je deze in Windows 7 wilt installeren dan resulteert dit in een foutmelding, het pakket controleert namelijk of het wel op Vista wordt geïnstalleerd:

image

Om deze controle te omzeilen kun je het bestand installeren in zogenaamde Silent Mode. Dat doe je door een ‘elevated’ command prompt te starten (klik met rechts op het Command Prompt icoon en kies Als Administrator uitvoeren). In dit venster navigeer je naar de directory waar EMSVISTA.MSI staat. Vervolgens start je de installatie met het commando:

msiexec /i esmvista /q

Geef de installatie even de tijd en kijk in het Gebeurtenislogboek (eventlog) of de installatie geslaagd is. Als het goed is vind je in je startmenu nu een snelkoppeling naar Exchange System Manager.

Let op: Deze oplossing wordt niet ondersteund door Microsoft.

Als je beschikt over Windows 7 Professional, Enterprise of Ultimate dan is er een alternatief wat wel ondersteund wordt. Namelijk het gebruik van Windows XP Mode, download het hier. Voor een korte overview van Windows XP Mode en heo het werkt verwijs ik je naar een blogppost van Daniel van Soest.

Met Windows XP Mode kun je ESM installeren op Windows XP dus je hebt geen problemen met compatibiliteit of ondersteuning. Toch kun je de applicatie gewoon vinden in je Windows 7 startmenu en er mee werken alsof het lokaal op Windows 7 geïnstalleerd zou zijn. Aanrader!

Wednesday, November 4, 2009

Exchange 2007 en Windows Server 2008 R2 (update)

Eerder schreef ik over de keuze van Microsoft om Exchange 2007 SP2 niet te gaan ondersteunen op Windows Server 2008 R2. De reden was dat er geen tijd in het testen en oplossen van issues werd gestoken omdat men die energie liever in Exchange 2010 SP1 wilde steken. Veel gebruikers hebben aangegeven toch graag Exchange 2007 op Server 2008 R2 laten draaien, en de Exchange product group heeft geluisterd: Exchange 2007 SP2 zal ondersteund gaan worden op Windows Server 2008 R2. Details volgen nog.

Monday, November 2, 2009

Server voorbereiden op Exchange 2010

In een recent artikel schreef Peter Noorderijk over het voorbereiden van een Windows server op de installatie van Exchange 2010. In dit artikel wil ik nog een derde variant beschrijven, namelijk het gebruik van ServerManagerCMD.exe en xml-files.

Wanneer we de installatiebestanden van Exchange 2010 downloaden of op DVD hebben dan staat in de installatiedirectory een directory met de naam Scripts. Hierin vinden we een aantal xml-bestanden:

Exchange-Typical.xml
Exchange-CAS.xml
Exchange-Hub.xml
Exchange-MBX.xml
Exchange-UM.xml

Deze bestanden kunnen we gebruiken als invoerbestand voor ServerManagerCMD.exe met de switch -ip. Voor een server die alle standaard Exchange 2010 rollen gaat draaien bijvoorbeeld gebruiken we het commando:

ServerManagerCMD.exe -ip Exchange-Typical.xml -Restart

Voor een Edge Transport server ziet het commando er zo uit:

ServerManagerCMD.exe -ip Exchange-Edge.xml -Restart

Goed, wat de bedoeling van de overige bestanden is spreekt wel voor zich, denk ik. Dan zijn er verder nog twee bijzonderheden, ten eerste voor een server die de Unified Messaging rol uit gaat voeren. Voor deze installeren we ook nog de Desktop Experience feature met het volgende commando:

ServerManagerCmd -i Desktop-Experience

En tot slot moeten we voor servers met de Client Access rol een service op 'Automatic' zetten, wat is er handiger om dit ook met een makkelijke opdrachtregel te doen:

sc config NetTcpPortSharing start= auto

Nu zul je misschien zeggen dat je het net zo makkelijk in de GUI kunt doen allemaal, en dit lijkt misschien wel eens handiger. Maar wanneer je 4 servers of 40 servers moet inrichten dan is het alweer een heel stuk makkelijker om de opdrachten in een script of batch-bestand te zetten en deze op de servers te laten draaien.

Een ander voordeel van de commandline is de mogelijkheid om heel eenvoudig een logboek bij te kunnen houden van alle stappen die je genomen hebt. Het maken van screenshots kost tijd en is vaak wat omslachtig, maar een snelle copy-paste van de gebruikte commando's is zo gedaan. Als je nog geen logboek bijhoudt, dan raad ik het je bij deze aan.