5ain7 ga11 . CH || i7-l3ak5. CH || g07r007.CH

Exchange routing groups werden benötigt, wenn man eine Exchange 2003 – Exchange 2003 mixed Infrastrukur hat.

Der Exchange 2003 Server versteht keine Sites. Mit foldenen Befehlen kann man die Routings Groups genauer analysieren:

<get-routinggroupconnector>

=> listet eine grobe Übersicht über die vorhandenen RGCs

<get-routinggroupconnector | fl>

=> listet alle vorhandenen Infos über alle Gruppen auf (unübersichtlich)

<get-routinggroupconnector |fl targetroutinggroup,targettransportservers,sourcetransportservers>

=> listet überisichtlich die Target und Source Server der entsprechenden Gruppe auf

<get-routinggroupconnector |fl targetroutinggroup,targettransportservers,sourcetransportservers,cost>

=> listet zusätzlich noch die Kosten der Verbindung auf

Wie erstellt man jetzt eine neue Routing Group, z.B. für eine Exchange 2003-2010 Transition? Grundsätzlich wird die RGC automatisch erstellt, sollten jedoch der Mailflow nicht möglich sein, dann kann die RGC mit folgendem Befehl entfernt werden:

<remove-routinggroupconnector -identity “Exchange RGC”>

Eine neue RGC wird mit:

<New-RoutingGroupConnector -Name “Exchange RGC” -SourceTransportServers “Ex2010Hub1.contoso.com” -TargetTransportServers “Ex2003BH1.contoso.com” -Cost 10 -Bidirectional $true -PublicFolderReferralsEnabled $true>

erstellt.

 

 

 

Die Exchange 2010 Server Installation benötigt eine Unmenge an Komponenten ohne welche die Installation nicht durchgeführt werden können. Vorraussetzungen sind:

• Microsoft .Net Framework 3.5
• Windows Remote Management 2.0
• Windows PowerShell v2
• ASP.NET AJAX 1.0

 

Wenn bei der Installation die Meldung kommt:

• Unable to read data from the Metabase. Ensure that Microsoft Internet Information Services is installed.

oder

• Unable to access the ‘Default Web Site’ on this computer.

 

..dann fehlen noch folgende Rollen oder Features, welche über den ServerManager installiert werden müssen:

ServerManagerCmd -i Web-Server

ServerManagerCmd -i Web-ISAPI-Ext

ServerManagerCmd -i Web-Metabase

ServerManagerCmd -i Web-Lgcy-Mgmt-Console

ServerManagerCmd -i Web-Basic-Auth

ServerManagerCmd -i Web-Digest-Auth

ServerManagerCmd -i Web-Windows-Auth

ServerManagerCmd -i Web-Dyn-Compression

ServerManagerCmd -i Web-WIM-Compression *NEW*

ServerManagerCmd -i NET-HTTP-Activation

ServerManagerCmd -I RPC-over-HTTP-proxy

 

Die Installationen lassen sich auch einfacher via PowerShell installieren:

Import-Module ServerManager

Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy -Restart

Set-Service NetTcpPortSharing -StartupType Automatic

 

Danach sollten alle Anforderungen erfüllt sein.

Was sind die Vorteile dieser Variante gegenüber dem Mapping mit LoginScripts?

• funktioniert scriptlos
• ermöglicht den entsprechenden Supportern ein einfaches Verwalten von Drive Maps
• es werden nicht massig Laufwerkbuchstaben verwendet
• Zuweisung der Folders kann von GL oder anderen berechtigten Personen einfach vorgenommen werden
  (Rechte Gruppenzuweisung im AD an gewünschte Person geben)
• es ist übersichtlich inline dokumentiert, welcher Mitarbeiter, Zugriff auf welche Folders haben

 

Beispiel Situation:

Root-Folder

c:\Daten  => Freigegeben als \\DC01\Daten

Subfolders

C:\Daten\Buha

C:\Daten\IT

 

2 User: hans.dampf, hans.nerd

hans.nerd

soll Zugriff auf Buha und IT haben

hans.dampf

soll Zugriff nur auf Buha haben

Die Mainfolders dürfen nicht verändert werden können, in den Subfolders sollen sie volle Berechtigungen haben.

 

Share freigeben:

Share freigeben und “Access Based Enumeration” aktivieren:

 

Berechtigungsvergabe:

Root-Folder

Berechtigungen auf Root Folder C:\Daten

 

Sicherheitsberechtigungen auf dem Root-Share (C:\Daten) für die Gruppe, welche auf den Laufwerk-Pool Zugriff haben sollen (z.B. alle Mitarbeiter)

=> Mitarbeiter dürfen Root Share nicht verändern können.

 

Subfolders:

Spezielle Berechtigungen für die Gruppe, welche den Ordner benutzen dürfen.

Beispiel C:\Daten\Buha

Spezielle Berechtigungen für Folder, Subfolder und Files:

 

Zweiten “Permission” entry hinzufügen:

Berechtigungen für Subfolders and Files only:

 

Drive Mapping via GMPC:

Anschliessen kann der Root Folder im AD wie folgt gemappt werden:

User Configuration\Preferences\Windows Settings\Drive Map

Im Register “Targeting” die Gruppe wählen, welches das Root Drive verbunden haben soll.

Folders freischalten:

In diesem Fall bekommen die Members der Gruppe “Alle Mitarbeiter” den Root Folder. Möchte man jetzt die einzelnen Main Subfolders
den Users freigeben, so kann man die gewünschten User in die entsprechende AD Gruppe hinzufügen:

Gruppe DL_DC01_Buha

 

Gruppe DL_DC01_IT

 

Screenshot der UserSessions:

Nach dem Login sollte folgendes ersichtlich sein:

Hans Dampf

 

Hans Nerd

 

 

 

Wenn die Windows Server 2008 R2 integrierte Windows Sicherung nicht auf anhieb auf ein Synology NAS  via UNC backup“en“ will, dann kann es am SMB Flag „strict allocate=yes“ liegen.

In der Ereignisanzeige sind die Fehlermeldungen nicht gut ersichtlich. Abhilfe schafft da die XML Ansicht.

Die Fehlermeldung besagt:

The version does not support this version of the file format.

Die gleiche Meldung erhält man auch, wenn man im cmd den Befehl:

<WBADMIN START Backup>

 eingibt. Dort gelangt man direkt zu dieser Meldung, ohne danach zu googeln.

Nach einem  Blick in die Synology Whitepapers habe ich herausgefunden, dass das Problem das Handling mit grossen Windows Files auf dem „Linux SMB Server sind“. Abhilfe schafft das SMB Flag:

Strict allocate=yes (in der globalsection hinzufügen) und mit

“/usr/syno/etc/rc.d/S80samba.sh restart

den Dienst rebooten.

Den Backup- Job kann mit

WBADMIN START Backup nochmals manuell gestartet werden.

 

Infos zu „strict allocate=yes“

———-

strict allocate S 3.0.9

Dies ist ein boolescher Parameter, er kontrolliert die Behandlung der Plattenplatz-Reservierung auf dem Server. Wenn dieser Parameter mit dem Wert yes belegt ist, wird der Server sein Unix-Verhalten beim Allozieren von Disk Storage Blocks verändern. Unix vergibt normalerweise keine echten disk storage blocks, wenn eine Datei im Windows-Modus auf einen bestimmten Wert vergrößert oder neu erzeugt wird. Im Windows-Modus (und das ist das Verhalten, welches dann in Kraft tritt), werden dann im Gegensatz dazu echte disk storage blocks erzeugt, wenn eine Datei im Windows-Modus auf einen bestimmten Wert vergrößert oder neu erzeugt wird. Im Unix-Jargon bedeutet das, Samba wird keine kleinen Dateien erzeugen und das kann manche System sehr stark verlangsamen.

Falls der Parameter mit dem wert no belegt ist, wird der Server sehr wohl sparse disk block allocation betreiben, wenn eine Datei erweitert (oder erzeugt) wird.

Setzt man den Wert auf yes, dann kann das bei Systemem, die restriktives Quota für die einzelnen Clients eingerichtet haben, helfen, die Messages bezüglich des Quotas zu retournieren.

Voreinstellung:

strict allocate = no

——————