So Welcome on one of the many technical blogs out there on the web. So what is special about this blog? Well absolutely nothing :) ... This is the place where I store handy information I don't want to forget, while hoping that in the process I'm also helping some other poor soul on the web that is facing similar issues, or is interested in similar topics.
So who am I?
My name is Mark Priem, I was build in 1981 and live in the Netherlands together with my two sons, Roan and Levi, and my Wife Mylene (note the capital W... You know who's boss now), who I all love to death.
Aside from spending as much time as possible with my family I enjoy sports and socializing face to face and online. Your average Joe right? The little time that is left I spend on technology; My main focus currently is SharePoint and cloud solutions, which I work with on a daily basis as part of my Job, Consultant at Microsoft. As I'm a Microsoft Certified Master in SharePoint 2010 I think I can say I know a thing or two about SharePoint, which I hope has a positive effect on the quality of my posts.
If however you find any misinformation or plain wrong content, please let me know. We all make mistakes right? :)
Please enjoy your stay and let me know what you think by commenting to my posts.
Thanks!
Mark
Tijdens het troubleshooten van mailservers zijn SMTP reply codes en SMTP status codes vaak waardevolle bronnen van informatie. Je moet echter wel begrijpen wat deze codes inhouden. Vandaar dat ik hier een overzicht post met de meest voorkomende codes.Veelal zie ik SMTP reply codes en SMTP status codes door elkaar gebruikt worden alsof ze hetzelfde zijn. Dit is echter niet zo. De status codes zijn gespecificeerd in verschillende RFC's en door de jaren heen zijn er verschillende uitbreidingen geweest. Ik zal niet ingaan op RFC nummers, maar het zit als volgt. Een SMTP server heeft een aantal standaard reply codes om aan te geven wat de return waarde is bij een bepaald commando wat meegeven wordt tijdens de SMTP sessie. Zo is 250 een code wat aangeeft dat het commando met een positief resultaat is uitgevoerd. Deze codes zijn redelijk beperkt en door de jaren heen zijn er extra RFC's geschreven voor wat uitgebreidere status meldingen. Deze zijn echter niet als SMTP reply code geimplementeert in het SMTP protocol, maar worden als 'message' of 'comment' teruggegeven in combinatie met een SMTP reply code.
Een voorbeeld is:
550 5.7.1 Client does not have permissions to send as this sender
550 is de SMTP reply code en 5.7.1 is de status code van het systeem
Hieronder zal ik een tweetal overzichten posten:
Let wel... De response varieert van systeem tot systeem. Let vooral op de code en de daarbij horende uitleg. Het doel van een bepaalde code is vastgelegd in RFCs, en zal daardoor (bijna) altijd gelijk zijn
SMTP reply codes:
SMTP status codes:
Exchange server performance troubleshooting is in Exchange 2000|3 perfect beschreven op technet.
Voor Exchange 2007 is er echter nog geen revisie op dit artikel. Voor het troubleshooten is dat echter geen ramp aangezien je hiervoor de Troubleshooting Assistent hebt. Dit is echter bedoelt om een systeem te bewerken welke al live is.
Voor het pre-deployment testen van Exchange met bijv. Jetstress heb je echter wat meer achterliggende info nodig. Iemand bij Microsoft is zo aardig geweest alvast wat performance counters vrij te geven.
Het moge duidelijk zijn. Public folders managen in Exchange 2007 zonder sp1 is ruk. Toch kan je het jezelf makkelijk maken door gewoon de system manager te gebruiken van Exchange 2003. Echter er is 1 probleem... Je kan geen verbinding maken met een public folder store op een 2007 server... The requested operation is forbidden
Of toch wel?
Ja dus...Om verbinding te leggen met een public folder store op een 2007 server met de System Manager van 2003 moet je het vereiste voor 128bits ssl encryptie van de ExAdmin en Public virtual directories halen op je Exchange 2007 server in de IIS manager.
Gisteren is de tweede update rollup voor Exchange 2007 gelanceerd. Naast de in rollup 1 aanwezige fixes bevat deze de volgende critical security fixes:
De bestanden zijn HIER te downloaden.HIER vind je meer informatie over de security fixes.
Voor wanneer je begint met het scripten voor Exchange 2007 wil ik je een aantal tips meegeven:
quickref
Set-ExecutionPolicy unrestricted
PowerShell.exe -PSConsoleFile "C:\Program Files\Microsoft\Exchange Server\Bin\ExShell.Msc1" -Command ."scriptnaam.ps1"
Set-PSDebug -Trace 2 -Step
$AdminSessionADSettings.ViewEntireForest=$true
get-mailboxdatabase
-status
Set-PSDebug -Strict
Split-path $MyInvocation.Mycommand.Definition
Set-ItemProperty HKLM:\SOFTWARE\Microsoft\PowerShell\1\PowerShellSnapIns\Microsoft.Exchange.Management.PowerShell.Admin -Name LogpipelineExecutionDetails -value 1
Exchange 2007 komt met een nieuw delegatiemodel gebaseerd op een aantal rollen. Op het eerste gezicht is dit dus niet veel anders dan Exchange 2003, maar toch zijn er een aantal significante wijzigingen.Waren de permissies die behoorden tot de rollen in 2003 impliciet te delegeren via de Exchange system manager; de rollen in Exchange 2007 zijn, op de Server Administrator na, expliciet te zetten door een security enabled object lid te maken van een of meerdere Universal Groups in het root domain.De rollen zijn als volgt:
Zoals al gemeld zijn de eerste drie rollen terug te vinden als Universal Group in een nieuw aangemaakte OU, 'Microsoft Exchange Security Groups', in het root domain.
Organization AdministratorZoals de naam al doet vermoeden is een organization administrator in staat om op organisatieniveau zaken te bewerken. Het gaat echter verder dan dat. Een Organization Administrator is in principe in staat om ALLES te wijzigen wat met Exchange 2007 te maken heeft. Hij heeft dus naast de rechten om organisatie brede eigenschappen aan te passen, ook rechten op elke Exchange server en de Exchange propery sets. In het dagelijks beheer is het dus niet verstandig om beheerders standaard Organization Administrator te maken. Dit zou in principe een rol moeten zijn die bij changes aangevraagd en geaudit moet worden.
View Only AdministratorEen view only administrator is in staat de configuratie van Exchange in de Configuration partitie van Active Directory uit te lezen. Hij heeft standaard echter geen rechten op een Exchange server en is daardoor niet zo View-Only als je zou denken. Zo kan je geen informatie over Client Access virtual folders (zoals OWA en ActiveSync) uitlezen en kan je ook de status van bijvoorbeeld de databases niet uitlezen. Om ook deze te kunnen uitlezen heb ik de volgende workaround gevonden. Let wel, dit is niet gebaseerd op officiele documentatie, maar is in mijn optiek redelijk secure. Voer het volgende uit:1. Sta toegang tot de IIS metabase toe door een van de volgende commandos te draaien op de Exchange server:
%windir%\Microsoft.NET\Framework\v2.0.50727>aspnet_regiis -ga Werkt alleen vanaf ASP.NET 2.0, dus in principe wel op elke Exchange 2007 server
%windir%\Microsoft.NET\Framework\v2.0.50727>aspnet_regiis -ga
cscript Metaacl.vbs "IIS://Localhost/W3SVC" REMetaacl moet je wel eerst HIER downloaden
cscript Metaacl.vbs "IIS://Localhost/W3SVC" RE
2. Sta toegang tot het remote registry toe door Lees rechten te geven op de HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\ winreg key.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\ winreg
3. Sta voldoende DCOM permissions toe door een security enabled object lid te maken van de 'Distributed Com Users' local group op de Exchange server OF Access permissies toe te staan in component services. Dit gaat als volgt:- Open de 'Component Services' snapin (comexp.msc) en selecteer Computers > My Computer > DCOM Config > IIS WAMREG admin service > Properties.- Selecteer de Security tab en allow remote en local access en activation permissies.Persoonlijk voel ik meer voor de laatste optie omdat deze alleen toegang biedt tot de IIS service en niet tot alle COM applicaties.Recipient AdministratorDe Recipient Administrator vind ik persoonlijk als rol echt een giller. Het staat toe dat over het gehele forest de Exchange property sets gewijzigd kunnen worden. Een Recipient Administrator kan dus standaard, zonder bijvoorbeeld aanvullende AD rechten als account operator, ALLE Exchange properties wijzigen en ook bijvoorbeeld mailboxen aanmaken op servers in andere domains.Op zich heel leuk voor de wat kleinere organisaties, maar ik had persoonlijk liever gezien, dat men via bijvoorbeeld lidmaatschap van een andere groep een en ander nog wat kon beperken. Gelukkig is dit redelijk simpel te verwezenlijken, maar het blijft maatwerk, wat ik niet zo charmant vind. Wat je doet met de volgende procedure is een aantal nieuwe Security Groups aanmaken die je gaat gebruiken om rechten te delegeren op container niveau in Active Directory.
Voordat je begint, double en tripple-check de commando's voordat je begint!!!!
1. Meld aan met een Domain Admin Account op een Exchange server.
2. Maak de gewenste UNIVERSAL security groups aan.
3. Open de Exchange management shell en voer de volgende commando's uit:
Add-ADPermission –identity "ou=OUnaam,dc=bedrijf,dc=com" –user "domain\group" -AccessRights ReadProperty, WriteProperty -Properties Exchange-Information, Exchange-Personal-Information, legacyExchangeDN, displayName, adminDisplayName, displayNamePrintable, publicDelegates, garbageCollPeriod, textEncodedORAddress, showInAddressBook, proxyAddresses, mail
Add-ADPermission -identity "ou=OUnaam,dc=bedrijf,dc=com" –user "domain\group" -AccessRights GenericRead
Add-ADPermission -identity "ou=OUnaam,dc=bedrijf,dc=com" –user "domain\group" -AccessRights GenericAll –InheritanceType Descendents -InheritedObjectType msExchDynamicDistributionList
Add-ADPermission -identity "ou=OUnaam,dc=bedrijf,dc=com" –user "domain\group" -AccessRights CreateChild, DeleteChild -ChildObjectTypes msExchDynamicDistributionList
Add-ADPermission -Identity "CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=CompanyOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=com" -User "domain\group" -InheritedObjectType ms-Exch-Exchange-Server -ExtendedRights ms-Exch-Recipient-Update-Access -InheritanceType Descendents
Add-ADPermission –identity "CN=Address Lists Container,CN=ExchOrganisatieNaam,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=bedrijf,DC=com" –user "<domain\group>" -AccessRights WriteProperty -Properties msExchLastAppliedRecipientFilter, msExchRecipientFilterFlags
Add-ADPermission –identity "CN=Recipient Policies,CN=ExchOrganisatieNaam,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=com" –user "" -AccessRights WriteProperty -Properties msExchLastAppliedRecipientFilter, msExchRecipientFilterFlags
Vervang alles wat schuingedrukt is met de juiste waardes voor jouw organisatie. Je kan deze commando's gebruiken op elke domein- of OU container.
4. Voeg de beheerders accounts to aan de juiste Security Group.
Je hebt nu voldoende toegang verleend om exchange recipient management te doen op mailenabled objecten in een bepaalde container. Het enige wat nog steeds kan is een mailbox aanmaken op elke server. Ik ben er nog niet echt achter hoe je dat kan beperken, maar misschien komt dat nog.Server AdministratorDe server administrator is een impliciete rol, welke bestaat uit lidmaatschap van de 'Exchange View-Only Adminstrators' Universal Group, 'Administrators' local group op de betreffende server(s) en lees/schrijf rechten op het/de server object(en) in de configuration partitie in Active Directory. Let wel, zet deze rol niet zelf via raw editing tools, maar gebruik de Exchange tools.De server administrator is in staat een individuele Exchange server te beheren.
Delegatie van rechtenHet delegeren van rechten is relatief simpel te doen via de Exchange Console. Selecteer de Organization Node en kies voor 'Add Exchange Administrator'
Je kan het ook doen via de Exchange Shell, maar ik gebruik dit zelden. Gebruik het volgende commando:
Add-ExchangeAdministrator -Identity -Role [-DomainController ] [-Scope ]
De scope parameter wordt alleen gebruikt bij de Server Administrator, waar je 1 of meerdere servers op kan geven
Property SetsBij de recipient administrator heb ik laten zien hoe je permissies delegeert op container niveau. Dit waren slechts een paar ACE's wat een heel verschil was met de manier waarop het in Exchange 2000|3 ging. De reden is dat met Exchange 2007 de properties (attributeSchema's) zijn gegroepeerd in property sets. Klinkt allemaal leuk, maar wat is nou een property set?Simpel gezegd is een property set dus een groepering van attributen, op basis waarvan rechten gedelegeerd kunnen worden.Als je op zoek gaat naar een propertyset als object in het schema zul je het niet terug vinden. Een propertyset wordt gedefinieerd door een controlAccessRight object aan te maken in CN=Extended-Rights,CN=Configuration,DC=bedrijf,DC=com en de rightsGuid te koppelen aan het attributeSecurityGUID property van een verzameling attributeSchema objecten in het Schema.
In het screenshot heb ik de attributen, behorend tot de 'Exchange Personal Information' property set opgehaald, om een en ander te visualiseren.
Zoals, eerder gemeld is dit, in vergelijking met Exchange 2000|3 een hele verbetering, doordat deze groepering niet bestond. Aan de andere kant is dit wel een erg zwakke implementatie. Het attributeSecurityGUID property op een attributeSchema object accepteert slechts 1 GUID octet, wat dus impliceert dat een attribuut slechts tot 1 property set kan behoren. Redelijk zwak in mijn optiek, maar beter iets dan niets. Dit is trouwens ook de reden dat wanneer je in ADSI gaat kijken naar de rechten delegatie voor bijvoorbeeld de Recipient Administrator, dat je attributen als Proxyaddresses en mail apart gespecificeerd ziet staan. Zij zijn namelijk al lid van de 'Public Information' property set.
Bronnen:
http://www.microsoft.com/technet/prodtechnol/exchange/E2k7Help/61080b45-8bce-4c23-b744-ed264d5f0b7d.mspx
http://www.microsoft.com/technet/prodtechnol/exchange/E2k7Help/2964c198-e624-46a1-ad3b-2e4f529466e3.mspx
http://msexchangeteam.com/archive/2007/02/12/435171.aspx
http://support.microsoft.com/kb/934761
http://blog.joeware.net/2006/01/18/216/
VSS of Volume Shadow Copy Service is een van de meest onderbelichte onderdelen van de laatste Windows besturingssystemen (XP, 2003, Vista, Longhorn). Ikzelf heb er nooit echt aandacht aan besteed, tot de vraag rees wat VSS backups van Exchange voor voordelen heeft.Om die vraag te kunnen beantwoorden moest ik eerst zien uit te zoeken hoe VSS nou eigenlijk in elkaar steekt.De Volume Shadow Copy Service is in essentie niet een Windows Service zoals de naam doet vermoeden, maar meer een concept of architectuur. Het bestaat uit een aantal onderdelen zoals in onderstaande screenshot is gevisualiseerd:
De requestor is hetgene wat de backup aanvraagt, zoals bijvoorbeeld een backup tool; de provider is hetgene wat de shadow copy maakt en beheert en de writer is hetgene wat applicatiespecifieke data klaarzet om te laten meenemen in de shadow copy. In het geval van Exchange 2007, zorgen de Exchange VSS writers ervoor dat de laatste logfiles uit het geheugen naar de database geflushed worden, de E00.log (de actieve log file) wordt gesloten, een tijdelijke E00tmp.log wordt aangemaakt, en de database wordt in read only mode gezet. Nu kan het creeeren van de shadow copy beginnen.Zo op het eerste gezicht lijkt het op een normale backup. In Exchange 2003 gebeurde iets soortgelijks om ervoor te zorgen dat de inhoud van de database niet wijzigt gedurende de backup. Als je wijzigingen toestaat tijdens de backup, krijg je namelijk inconsistentie in de database. Pages waarnaar verwezen wordt in records die al in de backup set zitten, zouden ineens verwijdert kunnen worden en dus niet meenomen worden in de backup. Dat willen we uiteraard niet.Maar de voorbereiding is ook het enige wat overeenkomt tussen de oude Exchange streaming backup (backuppen via de information store service) en de Shadow Copy.Een shadow copy kan OF een complete kopie zijn van de data of een snapshot. In Microsoft termen is een kopie een clone of split-mirror, waarbij bij de creatie van een clone een complete kopie gemaakt wordt op het moment dat de requestor een shadow copy aanvraagt, en een split-mirror gaat uit van een bestaande mirror van de data die op het moment dat de backup wordt aangevraagd, wordt losgekoppeld van de data zodat de wijzigingen niet langer gemirrord worden (deze methode vind je meestal alleen terug in hardware VSS oplossingen). Bij een snapshot wordt er door Microsoft gesproken over copy-on-write. Dit is - wat ik niet wist - al een hele oude techniek die terug te vinden is in bijvoorbeeld het EXT3 filesysteem maar ook in Unix implementaties van virtual memory en verschillende Virtualisatie producten. Het werkt als volgt:
Op het moment dat de Exchange VSS writers de data hebben klaargezet voor de Shadow Copy, bevriest Windows de harddisk sectoren waar de Database op staat en creert een shadow storage file waarin de gewijzigde sectoren opgeslagen worden. Elke write naar de orginele dataset vind gewoon plaats, maar voordat de sector overschreven wordt, wordt deze gekopieerd naar de shadow storage file. Een soort filter driver in kernel mode (VOLSNAP.SYS) vangt alle lees en schrijf operaties af en bepaald of een sector gekopieerd moet worden voordat deze overschreven is. Dit werkt dus op harddisk sector niveau. Dit zijn dus geen NTFS clusters; VOLSNAP heeft geen weet van de Master File Table, omdat het op een lager niveau dan het filesystem werkt. Het zit tussen het filesystem en de device drivers in.Applicaties kunnen op deze manier nog op de normale manier gebruik blijven maken van de data. Wanneer nu een backup gestart wordt van de snapshot, worden alle niet gewijzigde sectoren van de standaard locatie gelezen en alle gewijzigde sectoren van de shadow storage file. VOLSNAP bepaalt waar de sectoren te vinden zijn.Na de backup wordt de shadow storage meestal weer vrij gegeven. Deze kan echter bewaard blijven, maar zal dan uiteindelijk kunnen groeien tot dezelfde grootte als het orgineel voor de snapshot.
Zie de volgende pagina voor een schematisch overzicht...
Het voordeel van VSS voor Exchange is er in het geval van een clone backup nagenoeg niet. De database blijft read only gedurende de creatie van de shadow copy, net zoals de streaming backup bij Exchange 2003. Als je echter met een snapshot of split-mirror shadow copy werkt, vergt de creatie van de shadow copy slechts enkele seconden (het moet zelfs binnen 70 seconden anders failed de operatie), waarna de database weer vrijgegeven wordt voor schrijfacties. Op zich niet zo heel groot voordeel, maar in grote omgevingen liepen servers vaak tegen het limiet van 1024 uncommited logfiles aan, waarna de server crashte. Bij split-mirror heb je nog het voordeel dat je een backup kan doen op niet-productie LUNs.Een ander voordeel wat vaak genoemd wordt is het restoren van data. Microsoft schermt met tatements als 'Restore databases in minutes in stead of hours with VSS'
Dream on zeg ik dan. Ja, als je een snapshot online hebt staan kan je heel snel een stap terug in de tijd, maar hier heb je de orginele dataset nog voor nodig.Als je een volledige dataset kwijt bent, zul je toch ALLE data moeten restoren en dat is vergt gewoon tijd. Het moet immers van een backup medium naar een ander medium.
Het enige verschil wat ik nog zie ten opzichte van 2003 is dat het niet meer via de Information store hoeft, wat zeker een performance boost geeft.
Bronnen:http://blogs.msdn.com/adioltean/archive/2004/12/11/280052.aspx
http://technet2.microsoft.com/windowsserver/en/library/2b0d2457-b7d8-42c3-b6c9-59c145b7765f1033.mspx?mfr=true
Microsoft Windows Internals, 4th edition - Mark E. Russinovich and David A. Solomon
http://technet.microsoft.com/en-us/library/aa996004.aspx
Outlook Web Access wordt geinstalleerd met een aantal standaard webfolders in IIS. Om verbinding te kunnen maken met OWA, moet je voor Exchange 2003 verbinding maken met http:\\domein\Exchange en bij Exchange 2007 met https:\\domein\owa. Om ervoor te zorgen dat je direct naar OWA doorgezet wordt, doe je het volgende:
Wanneer nu naar de root van de website gebrowsed wordt, wordt men direct doorgerouteerd naar de OWA folder.
Daar aangekomen moet men zich aanmelden. Dit kan door gebruik te maken van de UPN of een domain/user combinatie. Je kan er echter ook voor zorgen dat gebruikers alleen hun usernaam hoeven te gebruiken. Hiervoor moet je echter wel forms-based authenticatie gebruiken.In Exchange 2007 staat dat standaard aan. De optie is te vinden door in de Exchange management console, in de Server Configuration de client access server te selecteren en de eigenschappen van de OWA virtual directory op te vragen. De optie is te vinden op de security tab. In een default installatie kan je ook het volgende cmdlet op de client access server draaien.
Set-owavirtualdirectory -identity "owa (default web site)" -FormsAuthentication:$true
Op diezelfde tab kan je ook bepalen hoe je de gebruikers wilt laten aanmelden; alleen met hun usernaam, met een domain/user combinatie of met de UPN.
In Exchange 2003 is dit wat lastiger. Het aanzetten van forms-based authentication gaat als volgt:
'iisreset /noforce'
Om gebruikers gebruik te laten maken van alleen hun username, moet de OWA logon pagina aangepast worden.. Om dit voor elkaar te krijgen ga je naar de directory die hoort bij de juiste TAAL (je browser bepaalt welke taal je voorgeschoteld krijgt, dus eigenlijk moet elke pagina aangepast worden. Je kan directories echter verwijderen, waardoor de default usa folder gebruikt wordt.)Browse naar de gewenste folder in %installdir%\exchweb\bin\auth\ en open de 'logon.asp' pagina in een editor.
%installdir%\exchweb\bin\auth\
Vervang de
met de volgende code:
Vergeet de niet te vervangen met het gewenste domein