Die Funktion zum Starten des Task-Managers kann durch das Setzen eines Registry-Keys deaktiviert werden. Hierzu muss unter

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System

der Wert des DWORD-Eintrags DisableTaksMgr auf 1 geändert werden. Sofern das Verzeichnis und/oder der DWORD-Eintrag noch nicht existiert, muss der Eintrag noch erstellt werden. Durch die Änderung in der Registry wird im Windows Security Screen der Eintrag Task-Manager ausgeblendet (oder es erscheint die Meldung, dass der Task-Manager deaktiviert wurde), allerdings bleiben noch weitere Optionen, wie z.B. Benutzer wechseln oder Benutzer abmelden:

Wenn alle Optionen auf dem Security Screen deaktivieren werden, erscheint dieser leer, wodurch der nächste Nutzer möglicherweise irritiert wird. In 32-bit Versionen von Windows XP und Windows Vista ließ sich der Zugriff auf das System in gewissem Maß anhand des Steady-State Tools verhindern. Allerdings wird dieses Tool von Windows 7 leider nicht mehr unterstützt.

Tasten deaktivieren

Eine Möglichkeit alle Tastenkombinationen zu unterbinden ist das komplette Deaktivieren einzelner Tasten, wie z.B. die Windows-Tasten, STRG, ALT, DEL, F10, sowie die Kontextmenü-Taste. Hierzu muss in der Registry unter

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout

den Wert des Eintrags Keyboard Layout geändert werden. Am Einfachsten geht dies über ein Reg-File mit folgendem Inhalt:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout]
"Scancode Map"=hex:00,00,00,00,00,00,00,00,09,00,00,00,00,00,5b,e0,00,00,5c,e0,00,00,5d,e0,00,00,44,00,00,00,1d,00,00,00,38,00,00,00,1d,e0,00,00,38,e0,00,00,00,00

Dieser Text wird in einen Texteditor kopiert und die Datei mit beliebigem Name sowie der Dateiendung „.reg“ abgespeichert und anschließend ausgeführt. Durch den Vorgang wird der Inhalt der Scancode Map überschrieben und damit die Tasten Windows-Taste, STRG, ALT, DEL, F10, sowie die Kontextmenü-Taste deaktiviert.

Die Funktionsweise (Hinweis: alle Werte sind hexadezimal):
Der Wert 09 nach den ersten 16 Nullen definiert die Anzahl der Tasten-Mappings. Dies sind in unserem Fall 9. Anschließend kommen 10 Nullen bis die eigentlichen Mappings beginnen. Hierbei bedeutet „5b e0 00 00“ das Deaktivieren der linken Windows-Taste. Im Folgenden werden alle verwendeten Mappings aufgelistet:

5b e0 – linke Windows-Taste
5c e0 – rechte Windows-Taste
5d e0 – Kontextmenü-Taste
44 00 – F10
1d 00 – linke Strg-Taste
38 00 – linke Alt-Taste
1d e0 – rechte Strg-Taste
38 e0 – rechte Alt-Taste

ACHTUNG:
Das systemweite Deaktivieren der Tasten STRG, ALT und ENTF führt dazu, dass diese Tasten auch beim Anmeldebildschirm nicht funktionieren. Somit lässt sich die Sichere Anmeldung mit STRG+ALT+ENTF nicht verwenden, die daher unbedingt vorher über die Benutzerkontensteuerung deaktiviert werden muss, weil sich der Nutzer sonst vom Zugriff auf das System ausschließt:

Start –> Ausführen –> „netplwiz“ –> Erweitert und Haken bei Strg+Alt+Entf drücken ist für die Anmeldung erforderlich entfernen

Weiterführende Links:

• http://support.microsoft.com/kb/126449 - Windows Shortcuts
• http://technet.microsoft.com/de-de/library/gg176676(WS.10).aspx - Steady State
• http://msdn.microsoft.com/de-de/windows/hardware/gg463447 – Scancode Mapping

Sicherheitshinweis: Bitte beachten Sie, dass Änderungen an der Registry einen tieferen Eingriff in das System darstellen und die fehlerhafte Bearbeitung der Registry zu gravierenden Problemen führen kann. Daher sollten Sie vor der Bearbeitung der Registry stets ein Backup der Registry durchführen. Wie Sie ein Registry-Backup erstellen können, wird in Sichern der Registry beschrieben.

Seit Exchange 2010 gibt es die sogenannte Role-Based-Access-Control (RBAC). Hiermit lassen sich die Berechtigungen des Exchange Administrators einer Subdomänen einschränken, die im Folgenden erklärt werden:

Das Was

Die Mitglieder unserer AD-Gruppe Subdomain-Admins sollen folgendes in der Subdomäne sub.test.local können:

• Server Management
• Recipient Management allerdings ohne den Befehl Remove-OwaMailboxPolicy
• View-Only Organization Management

Weitere Informationen zu diesen RoleGroups finden Sie unter [1].

Um die vorhanden RoleGroups nicht zu beschädigen oder einzuschränken, erstellen wir alle 3 RoleGroups neu:

$RoleGroup = Get-RoleGroup “Server Management”
New-RoleGroup “Subdomain Server Management” -Roles $RoleGroup.Roles

$RoleGroup = Get-RoleGroup “View-Only Organization Management”
New-RoleGroup “Subdomain View-Only Organization Management” -Roles $RoleGroup.Roles

Für die angepasste Rolle RecipientManagement wird das ganze etwas komplizierter. Da der Befehl Remove-OwaMailboxPolicy in den Rollen Mail Recipients und Recipient Policies enthalten ist, die beide ein Teil von Recipient Management sind, müssen wir das Ganze anpassen. Hierzu erstellen wir uns Kopien der entsprechenden Rollen:

New-Managementrole -Parent “Mail Recipients” -Name “Restricted Mail Recipients”

New-ManagementRole -Parent “Recipient Policies” -Name “Restricted Recipient Policies”

Nun müssen wir den unerwünschten Befehl entfernen:

Remove-ManagementRoleEntry “Restricted Mail Recipients\Remove-OwaMailboxPolicy”

Remove-ManagementRoleEntry “Restricted Recipient Policies\Remove-OwaMailboxPolicy”

Diese und alle anderen Rollen, die wir benötigen fügen wir nun zu einer RoleGroup Restricted Recipient Management zusammen:

New-RoleGroup “Restricted Recipient Management” -Roles “Distribution Groups”, “Mail Enabled Public Folders”, “Mail Recipient Creation”, “Message Tracking Migration”, “Move Mailboxes”, “Restricted Mail Recipients”, “Restricted Recipient Policies”

Weitere Infos zu ManagementRoles, die unter Exchange 2010 bereits existieren, finden Sie unter [2].

Das Wer

Jetzt müssen die gewünschten Mitglieder noch den RoleGroups hinzufügen werden. In unserem Fall die Gruppe Subdomain-Admins:

Add-RoleGroupMember”Subdomain Server Management” -Member Subdomain-Admins

Add-RoleGroupMember “Subdomain Recipient Management” -Member Subdomain-Admins

Add-RoleGroupMember “Subdomain View-Only Organization Management” -Member Subdomain-Admins

Das Wo

Die Rechte, die über RoleBased-Access-Control vergeben werden, können am einfachsten durch einen eigenen Scope auf bestimmte Bereiche einschränken. In unserem Fall müssen wir also die Subdomäne zu einem neuen Sub Scope zusammenfassen. Dies geht am einfachsten über den FQDN der beteiligten Server:

New-ManagementScope -Name “Sub Scope” -ServerRestrictionfilter {FQDN -like “*.sub.test.local*”}

Nun werden die zuvor erstellten RoleGroups dem Scope zugeordnet:

Get-ManagementRoleAssignment -RoleAssignee “Subdomain Server Management” | Set-ManagementRoleAssignment  -CustomConfigWriteScope “Sub Scope”

Get-ManagementRoleAssignment -RoleAssignee “Subdomain Recipient Management” | Set-ManagementRoleAssignment -CustomConfigWriteScope “Sub Scope”

Get-ManagementRoleAssignment -RoleAssignee “Subdomain View-Only Organization Management” | Set-ManagementRoleAssignment -CustomConfigWriteScope “Sub Scope”

Nach den durchgeführten Änderungen hat jedes Mitglied der Gruppe SubdomainAdmins alle nötigen Berechtigungen um den Exchange innerhalb der Subdomain, wie gewünscht, zu verwalten.

[1] http://technet.microsoft.com/en-us/library/dd351266.aspx
[2] http://technet.microsoft.com/en-us/library/dd638077.aspx

Genau das werde ich im Folgenden erklären:

Das versteckte Attribut

Durch das Verstecken des Attributs MyAttribut wird aus

diese LDAP-Anzeige:

Visible again

Um das Attribut für eine Gruppe Visible wieder sichtbar zu machen, muss der Administrator wie folgt vorgehen:

• ldp.exe öffnen
• über Connection -> Bind… sich mit einem Administrator-Account zum AD verbinden
• über View -> Tree das AD öffnen
• Ein Rechtsklick auf die oberste Ebene -> Advanced -> Security Descriptor öffnet das benötigte Fenster

Hier muss folgendes über Add ACE eintragen werden:

• Trustee:  DOMAIN\Visible
• ACE type: Allow
• Access mask: Control access
• ACE flags: Inherit
• Object type: MyAttribute

Durch das Bestätigen des Dialogs werden die Rechte entsprechend geändert, so dass die Mitglieder der Gruppe Visible das Attribut MyAttribut lesen können, obwohl es als confidential deklariert wurde.

Aber was ist die Cloud nun? Wie kann ich sie zu meinem Vorteil nutzen? Diese Fragen möchte ich im folgenden Artikel klären.

Eine Begriffsdefinition

Wer sich näher mit dem Thema Cloud auseinandersetzt, wird schnell darauf stoßen, dass es um Virtualisierung von Computersystemen geht. Virtualisierung kennen wir aber nun schon recht lange. Wo ist denn nun das fundamental neue Konzept, das eine eigene Marketing-Kampagne rechtfertigt?

Die Schwierigkeit daran, den Begriff Cloud zu definieren ist, dass hier eher versucht wird eine Idee zu benennen. Ein Beispiel: Wenn ich vor einem Computer stehe kann ich, nicht feststellen, ob es sich um einen Server- oder einen Client-PC handelt,  ohne mit ihm zu arbeiten. Der Unterschied liegt darin, dass der Server Dienste für Clients bereitstellt. Ähnlich stellt sich die Situation mit der Cloud dar. Sie ist Virtualisierung mit “ein bisschen mehr”.

Die Cloud vereint Virtualisierung mit (teilweise automatisiertem) Energie- und Ressourcenmanagement und erweiterter Ausfallsicherheit. Dadurch, dass nahezu alle Systeme virtualisiert sind, ist für den Klienten gar nicht wichtig, auf welcher Hardware er tatsächlich arbeitet. So können zum Beispiel bei geringer Last automatisch die benötigten Systeme auf wenigen physikalischen Maschinen zusammengefasst und der Rest ausgeschaltet werden.

Ist Cloud gleich Cloud?

Leider auch verfehltem Marketing geschuldet ist die Wahrnehmung, dass eine Cloud generell außerhalb des eigenen Rechenzentrums bestehen muss. Hier wird unterschieden zwischen der Private Cloud (oder in Microsoft-Terminologie die Hyper-V Cloud) und der Public Cloud. Bei der Public Cloud stehen die physikalischen Maschinen dabei in einem fremden Rechenzentrum, während die Private Cloud alleine im eigenen Haus arbeitet.

Welche Vorteile hat die Public Cloud?

Die Public Cloud nimmt dem IT-Administrator die Arbeit ab, Hardware beschaffen oder warten zu müssen. Er kann sich komplett auf die Administration der Software konzentrieren. Auch für Dienste, bei denen seltene, aber große Lastspitzen zu erwarten sind, ist die Public Cloud sinnvoll.

Ein fiktives Beispiel aus Sicht des KIT: Zu Beginn jedes Semesters müssen sich alle Studenten zu Seminaren anmelden. Die Anmeldung wird für alle Seminare gleichzeitig freigeschaltet und wer sich zu spät meldet bekommt häufig keinen Platz in den beliebten Seminaren. Um die Last abzufangen, muss das System auf ausreichend starker Hardware betrieben werden. Allerdings sprechen wir hier nur von wenigen Tagen im Jahr, in denen der Service überhaupt verwendet wird. Eine Public Cloud versetzt mich nun in die Lage, bei hoher Last weitere Rechenleistung hinzuzubuchen. Dadurch entstehen nicht das ganze Jahr unnötige Kosten.

Der größte Kritikpunkt an der Public Cloud sind generell Sicherheitsbedenken. Oft hört man davon, dass interne Daten nicht “in die Cloud” sollten. Die Sorge ist sicher nicht ganz unberechtigt. Die Daten liegen nicht mehr im eigenen Haus und können nicht unmittelbar kontrolliert werden. Bei einem seriösen Anbieter hält sich das tatsächliche Risiko allerdings in Grenzen. Es ist auch in der Public Cloud möglich (und sinnvoll) die eigenen Server mit Sicherheitssoftware auszustatten. Zusätzlich werden größere Rechenzentren von Fachkräften gesichert, die oft mehr Erfahrung mit der Materie haben, als die eigenen Administratoren.

Wir haben ein Rechenzentrum. Kann ich von der Cloud profitieren?

Abgesehen davon, Public Cloud und Private Cloud zu kombinieren, sollte jedes Rechenzentrum generell über den Aufbau einer Private Cloud nachdenken.

Speziell aus Sicht unserer Kunden, also Hochschulen, gibt es immer wieder Szenarien, die eine Private Cloud nahelegen. In der Regel hat nicht nur jede Fakultät, sondern sogar jedes Institut eine eigene Infrastruktur. Diese beinhaltet nicht nur Dienste wie Exchange oder File Server, die ohnehin in ein Rechenzentrum ausgelagert werden sollten, sondern gerade im Bereich Informatik auch viele starke Rechner für wissenschaftliche Berechnungen.
Diese Systeme werden nicht durchgängig benötigt, werden aber trotzdem für viel Geld angeschafft. Eleganter wäre hier der Weg in die Private Cloud. Der User kann beispielsweise über eine SharePoint-Seite ein Testsystem mit bestimmter Leistung anfordern. Es wird ein passendes Gastsystem gesucht und eine virtuelle Maschine eingerichtet. Nach einer gesetzten Zeit wird, wenn der User nicht widerspricht, die Maschine gelöscht und die Ressourcen freigegeben. Ein ähnliches Vorgehen ist auch für Software (z.B. Teile des Office Pakets, Adobe Reader, diverse Media Player, …) möglich. Das spart Lizenzen und hält die Client-Computer sauber. Letzteres Szenario bietet sich beispielsweise für Poolräume von Rechenzentren an.

Fazit

Man sollte sich nicht durch das Marketing der Cloud abschrecken lassen. Das Konzept bietet in seinen verschiedenen Ausprägungen viele Möglichkeiten. Generelle Virtualisierung der meisten Systeme empfiehlt sich ohnehin. Diese virtuellen Maschinen lassen sich gut über Microsofts System Center Virtual Machine Manager (SCVMM) verwalten. Damit ist die Grundlage für die Hyper-V Cloud bereits gesetzt. Ob darüber hinaus Cloud-Funktionen eingesetzt werden, muss jedes Rechenzentrum für sich entscheiden. Aus meiner Sicht können die meisten Anwender von einer Cloud allerdings nur gewinnen.

Stellen Sie sich nun folgendes Szenario vor: Sie setzen einen Server 2008 R2 in Hyper-V auf und konfigurieren Dynamic Memory:

Nach der Installation des Betriebssystems kommt nun die Überraschung: Der Server läuft nur mit dem Startup-RAM, in diesem Fall 512MB:

Mit exakt diesem Problem sah ich mich neulich konfrontiert. Zunächst habe ich versucht die Integration Tools erneut zu installieren um sicherzustellen, dass die neueste Version vorhanden ist. Auch dieses Vorgehen hat jedoch keinen Erfolg gebracht. Nach einiger Recherche habe ich in der TechNet im Artikel Hyper-V Dynamic Memory Configuration Guide die Lösung gefunden. Wenn es sich, wie in meinem Fall um einen Server 2008 R2 Standard handelt, so muss auch auf dem Gast-System SP1 für Server 2008 R2 installiert sein. Für alle Server 2003 und Server 2008 Versionen sowie für Server 2008 R2 Enterprise oder Datacenter genügt ein Update der Integration Tools.

Nach der Installation von SP1 funktionierte dann auch Dynamic Memory wie gewünscht:

Die einfache Antwort lautet in diesem Fall Mailbox Storage Quotas.

Was sind überhaupt Mailbox Storage Quotas und was kann ich mit ihnen einstellen?

Mailbox Storage Quotas sind grundsätzlich ein Speicherplatz-Limit für Exchange Postfächer. Darüber hinaus lässt sich einstellen, wie sich der Exchange Server verhält, sobald das eingestellte Limit erreicht wurde. Dafür gibt es folgende Optionen:

• Ab welcher Größe wird gewarnt, dass das Postfach zu groß wird.
• Ab welcher Größe wird das Senden neuer E-Mails verhindert.
• Ab welcher Größe wird das Senden und Empfangen von E-Mails verboten.

Die Einstellungen lassen sich für einzelne Mailboxen oder für eine ganze Datenbank vornehmen. Wenn ein Quota für eine Datenbank festgelegt wird, gilt es für alle Postfächer, die sich darin befinden, und kein eigenes Quota eingestellt haben.

Wie werden Mailbox Storage Quotas konfiguriert?

Grundsätzlich können die Mailbox Storage Qutas in der Exchange Management Console (EMC) oder über die Exchange Management Shell eingestellt werden.

In der EMC werden die Limits für die gesamte Datenbank wie folgt eingestellt:

1. Organization Configuration
2. Mailbox > Reiter “Database Management”
3. Eigenschaften der gewünschten Mailbox
4. Limits

Für einzelne User funktioniert die Einstellung wie folgt:

1. Recipient Configuration
2. Mailbox
3. Eigenschaften eines Users
4. Mailbox Settings
5. Storage Quotas

Darüber hinaus lassen sich diese Einstellungen auch über die Shell vornehmen. Dazu verwenden Sie folgende Befehle:

Set-Mailbox -Identity jsmith@contoso.com -IssueWarningQuota 209715200 -ProhibitSendQuota 262144000 -ProhibitSendReceiveQuota 293601280 -UseDatabaseQuotaDefaults $false

Dieser Code Ausschnitt setzt die Quotas für das Postfach jsmith@contoso.com. Außerdem wird nun das persönliche Quota und nicht mehr das allgemeine Datenbank Quota angewandt. Genauso lässt sich als Identity der Name einer Mailbox in der Form “Mailboxname” angeben (inklusive Hochkommata), wobei das UseDatabaseQuotaDefaults Argument entfällt und die übrigen Befehle identisch bleiben.

Zuerst wird das Service Pack installiert und anschließend der Server neu gestartet. Lässt man den Server nun laufen sieht das Eventlog bald wie im folgenden Bild aus:

Ein Blick in die Zentraladministration unter Upgrade and Migration -> Review database status zeigt für alle Datenbanken folgende Meldung:

Dieses Datenbank Upgrade kann über die PowerShell oder einfacher noch über den SharePoint 2010 Products Configuration Wizard vorgenommen werden. Dieser muss mit einem Account gestartet werden, der sowohl administrative Rechte auf dem SharePoint Server, als auch Schreibzugriff auf die Datenbank besitzt.

Möglicher Weise schlägt das Datenbank Upgrade für eine oder mehrere Datenbanken fehl. Das ist grundsätzlich kein Problem. Unter Upgrade and Migration -> Check upgrade status in der Zentraladministration lässt sich der Status des aktuellen Upgrades einsehen. Dort ist auch der Pfad zum passenden Logfile angegeben. In unserem Fall ist das Upgrade bei zwei Datenbanken fehlgeschlagen. Eine aussagekräftige Fehlermeldung gab es nicht. Nur den Hinweis es noch einmal zu versuchen. Ein zweiter Durlauf des Configuration Wizard brachte dann den gewünschten Erfolg.

Je nach Leistung des Servers und Größe der Datenbanken sollte für den ganzen Vorgang etwa eine Stunde eingeschränkte Erreichbarkeit für den SharePoint Server eingeplant werden.

Deshalb zeige ich hier, wie man ein Profil für viele Benutzer erstellt, dass nicht verändert werden kann: Ein sogenanntes Mandatory Profile.

Was genau ist ein Mandatory Profile?

Ein Mandatory Profile ist ein Profil, dass vom Administrator beliebig stalltet werden kann und von den Benutzern auch wie ein ganz normales Profil verwendet wird.
Einziger Unterschied: Änderungen vom Benutzer werden nicht gespeichert. Jeder Benutzer hat bei jeder Anmeldung immer das gleiche Profil.

Die Vorbereitungen

Zu aller erst brauchen wir ein Profil, das wir editieren können. Hierzu legen wir einfach über Active Directory Users and Computers einen neuen Benutzer Mandatory an. Damit das Profil später von allen nötigen Clients erreicht werden kann, legen wir außerdem einen Share MandProfile an und geben diesen für alle User mit Vollzugriff frei. Als nächstes legen wir noch fest, dass das Profil vom zuvor erstellen Benutzer Mandatory im neuen Share MandProfile liegen soll. Hierzu gehen wir in Active Directory Users and Computers mit Rechtsklick auf den Benutzer Mandatory und ändern den Profilpfad unter Properties -> Profile auf den gerade erstellen Share:

Nun melden wir uns an einem Client mit dem gerade neu erstellen User an, verändern das Profil wie gewünscht und melden uns wieder ab. Nun kann man den User Mandatory getrost wieder löschen, da er nicht mehr gebraucht wird.

Die Berechtigungen

Zu aller erst müssen wir die Berechtigungen auf die Profilordner ändern. Alle Ordner und Unterordner müssen über die folgenden Berechtigungen verfügen:

• Authenticated Users: Read & execute
• System: Full Controll
• Administrators: Full Controll (um später schnell Änderungen vornehmen zu können

Jetzt fehlen nur noch die Berechtigungen auf die NTUser.dat. Hierfür werden wir über den Registry-Editor einige Rechteanpassungen vornehmen:

• Wir wählen HKEY_LOCAL_MACHINE und fügen über File -> Load Hive… die NTUser.dat des Mandatory Profiles hinzu. Der Namen den wir vergeben müssen, ist beliebig und hat keine Auswirkungen auf das spätere Ergebnis
• Rechtsklick auf den gerade hinzugefügten Hive -> Permissions

• Hier setzen wir die Rechte für Authenticated Users auf Full Control
• Über File -> Unload Hive…entfernen wir den Hive wieder

Das Profil an die Benutzer verteilen

Jetzt muss das neue Mandatory Profile nur noch an die entsprechenden User verteilt werden. Es stehen zwei Möglichkeiten zur Verfügung:

• Active Directory Users and Computers -> Eigenschaften des Users -> Profile

• Computerconfiguration -> Policies -> Administrative Templates -> System -> User Profiles -> Set roaming profile path for all users logging onto this computer

 Die Volltextsuche wird durch sogenannte iFilter realisiert. Für die Volltextsuche in Microsoft-Dokumenten werden diese iFilter bereits mitgeliefert, für PDF-Dokumente muss ein solcher Filter erst installiert werden, eine native PDF-Unterstützung ist für die nächste Windows Version geplant. Wenn bereits ein PDF-Reader installiert ist, dann ist die Dateiendung *.pdf bereits registriert, jedoch ist die Volltextsuche aufgrund des fehlendes iFilters nicht möglich. Dies ist in den Indexing Options zu erkennen, diese werden am einfachsten durch das Drücken der Windows Taste und anschließende Eingabe von Indexing erreicht. Hier ist unter Advanced im Tab File Types folgendes zu sehen:

Glücklicherweise stellt Adobe einen passenden iFilter kostenlos zur Verfügung. Der Download ist auf der Adobe-Seite für 64-bit Systeme zu finden. Für 32-bit Systeme ist dieser Filter bereits in den Adobe Reader integriert und wird bei dessen Installation mit installiert.

In diesem Artikel möchte ich die Installation dieses iFilters mittels Gruppenrichtlinen beschreiben. Bei der von Adobe zum Download zur Verfügung gestellten Datei handelt es sich um eine *.msi Datei. Eine Installation sollte also mit Hilfe von Gruppenrichtlinien recht einfach zu erledigen sein. Die ausführliche Beschreibung hierzu ist in meinem früheren Artikel zum Java Deployment zu finden.

Die *.msi-Datei wird auf eine Share gelegt, am besten ist ein Zugang auf diesen Share per DFS. Nun erstellen wir auf einem Server eine neue Gruppenrichtlinie, diese kann auch direkt auf die gewünschte OU gelinkt werden. Über Rechtsklick->Edit wird der Gruppenrichtlinien-Editor geöffnet. Hier navigieren wir zu Computer Configuration -> Policies -> Software Settings -> Software Installation -> Rechtsklick -> New – > Package. Hier sollten Sie nun den UNC-Pfad, also \\Server\Ordner\ zu der *.msi-Installer Datei  angeben. Als Deployment Methode wählen wir Assigned, denn weitere Einstellungen sind hier nicht zu treffen.

Nun sollte das Deployment des iFilters funktionieren und dieser beim nächsten Neustart des Systems installiert werden. Erkennbar ist das auch an den Einstellungen zur Windows Suche:

Jedoch wird die PDF-Volltextsuche noch nicht funktionieren, da die PDF-Dateien noch nicht indiziert sind. Manuell lässt sich das in den Indexing Options über Advanced->Rebuild Index bewirken:

Jedoch ist dieses Vorgehen für ein Deployment auf vielen Rechnern nicht praktikabel. Leider bieten die zur Steuerung der Windows Search verfügbaren GPOs auch nicht die gewünschte Einstellung.

Zur Lösung dieses Problems habe ich mittels des Process Monitors aufgezeichnet, was passiert wenn man den Rebuild Button drückt. Nach einiger Analyse konnte ich feststellen, dass zu Beginn der Indizierung ein Registry-Key gesetzt wird, welche die Indizierung anstößt. Da sich dieser Registrykey bequem über GPO-Preferences verteilen lässt ist nun ein Weg gefunden um die Neuerstellung des Indexes auf allen Rechnern anzustoßen.

Hierzu können wir die bereits erstellte GPO verwenden, wir verteilen den Key über Computer Configuration -> Preferences -> Windows Settings -> Registry -> Rechtsklick New -> Registry Item:

Dieser Wert wird beim Start des Computers gesetzt, sobald der Windows Search Indexing Dienst gestartet ist erkennt dieser den Key, beginnt mit einer erneuten Indizierung und löscht den Key. Wichtig ist nun noch, dass im Tab Common das Häkchen bei Apply once and do not reapply gesetzt ist. Damit wird verhindert, dass der Index bei jedem Neustart erneut komplett neu erstellt wird, sondern das dies nur nach der Installation des iFilters erfolgt.

Nun sollte nach der Installation und nach dem Neuerstellen des Indexes, was je nach Anzahl der vorhandenen Dateien eine gewisse Zeit dauern kann, die Volltextsuche für PDFs funktionieren:

Unter Exchange 2010 gibt es standardmäßig die Möglichkeit, dass ein Benutzer über die OWA einige Attribute des eigenen Accounts ändern kann. Hierzu zählen zum Beispiel: Adresse oder Telefonnummer. Außerdem kann er sich selbst in öffentliche Verteilergruppen hinzufügen oder die Mitgliedschaft wieder beenden.

Dies ist nicht immer wünschenswert, darum zeige ich hier, wie solche Rechte vergeben bzw. einschränken werden können.

Zuerst sollten die grundlegenden Begriffe geklärt werden:

Management Role

Eine Management Role ist ein Recht, dass ein Benutzer hat, um zum Beispiel seine eigene Adresse zu ändern. Diese Berechtigungen werden über die MyAddressInformation Role verwaltet. Alle verfügbaren Management Roles sind unter [1] aufgelistet.

Role Assignment Policy

Eine Role Assignment Policy ist eine Art Sammlung von Management Roles. Diese Sammlung von Berechtigungen wird einer Mailbox zugeordnet. Einer Mailbox kann ausschließlich eine Role Assignment Policy zugeordnet werden. Das Zuordnen von einzelnen Roles oder mehreren Policies ist nicht möglich. 

Um eine Policy test zu erstellen, die dem Benutzer das Ändern der Adressdaten erlaubt,  wird in der ExchangeManagementShell folgender Befehl ausgeführt:

New-RoleAssignmentPolicy –Name test –Role MyAddressinformation

Um diese Policy einer Mailbox zuzuordnen, wird der folgende Befehl benutzt:

Set-Mailbox –Identity USERNAME –RoleAssignmentPolicy test

Jeder Exchange Server besitzt eine Default Role Assignment Policy. Diese wird jedem neu erstellten Benutzer automatisch zugeordnet. Um Änderungen an einer bestehenden Policy vorzunehmen sind folgende Informationen erforderlich:

• Name der Policy
• Name der zu Ändernden Role

Das Ziel

Um nun wie anfangs gefordert der Default Role Assignment Policy das Recht auf Adressänderung zu nehmen, benutzt man folgenden Befehl:

Set-ManagementRoleAssignment –Identity „MyContactInformation-Default Role Assignment Policy“ –Enabled $false

[1] Built-in Management Roles:
http://technet.microsoft.com/en-us/library/dd638077.aspx