Volume Shadow Copy Service (VSS) & Exchange

Posted over 7 years ago

by mpriem

• 1 Comment

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

Exchange 2007 permissie delegatie

Posted over 7 years ago

by mpriem

• 1 Comment

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 Administrator
Zoals 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 Administrator
Een 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

cscript Metaacl.vbs "IIS://Localhost/W3SVC" RE
Metaacl moet je wel eerst HIER downloaden

2. Sta toegang tot het remote registry toe door Lees rechten te geven op de HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\
SecurePipeServers\ winreg key.

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 Administrator
De 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 Administrator
De 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 rechten
Het 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 Sets
Bij 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/