Integration von Windows 10 und SBE

Um Windows 10 mit einer Small Business Essentials Umgebung (SBE) sind zwei Dinge notwendig.

  1. Installation des SBE Client Connectors auf dem Windows 10 Client
  2. Anpassung der GPO auf dem SBE

Ausgehend vom aktuellsten SBE, dem Windows Server 2012 R2 Small Business Essentials (egal ob Role oder SKU) sind dazu folgende Schritte notwendig.

Installation des Client Connectors

Ein Download des Connectors von http://sbe/connect endet in folgender Fehlermeldung.

image

An unexpected error has occurred. To solve this issue, contact the person responsible for your network

Um das Problem zu lösen muss der Client Connector in einer aktuallisierten Version installiert werden, dazu gibt es mehrere Möglichkeiten.

  1. Download und Installation auf Windows 10, sowie anschließender Verbindung mit dem SBE
  2. Update des SBE damit gleich der richtige Client Connector zur Verfügung gestellt wird

Blogs dazu gibt es viele – ein Blick zu Microsoft ist hier sicherlich der erste Weg.

https://blogs.technet.microsoft.com/sbs/2015/11/17/client-connector-availability-with-windows-home-server-small-business-server-and-windows-server-essentials-for-supported-client-os/

und natürlich Winking smile

https://sbsland.wordpress.com/2015/11/ 

Der Download für Windows 10 ist hier (KB2790621) erhältlich und das Update für den Server hier (KB310585). Wenn wir davon ausgehen, dass wir bestimmt mehrere Windows 10 Client zu versorgen haben, macht die Installation von KB310585 auf dem SBE 2012 R2 sicherlich mehr Sinn!

Die Umleitung der Ordner

Nachdem die Windows 10 Clients auch in der SBE Umgebung integriert sind, besteht die Möglichkeit die Ordner den Clients auf den Server um zu leiten. Das klappt für Windows 10 nicht und im Dashboard erscheint die folgende Meldung.

image

Dashboard / Devices / Group Policy / Not Applicable

Der Grund dafür ist ein WMI Filter, der entsprechend angepaßt werden muss. Microsoft beschreibt das in folgenden Blog-Beitrag:

https://blogs.technet.microsoft.com/sbs/2016/01/22/wmi-group-policy-filter-issue-on-windows-10-breaks-folder-redirection-windows-server-2012-r2-essentials-windows-server-2012-essentials-and-windows-small-business-server-2011-essentials/

Im Wesentlichen handelt es sich um folgende Änderung.

# Vorhandener WMI Filter
select * from Win32_OperatingSystem where (Version >= "6.1%") and ProductType= "1" 

# Neuer WMI Filter
select * from Win32_OperatingSystem where Version like "10.%" or Version >="6.1"

Enjoy it, b!

Entfernen von Exchange 2007 im Verlauf einer Migration

Im Verlauf einer Migration von Windows Small Business Server 2008 auf einer der neueren Essentials oder Standard Versionen, muss Exchange aus dem Active Directory sauber entfernt werden. Das passiert an einfachsten durch eine Deinstallation von Exchange auf dem alten Small Business Server.

Allerdings musste ich im Verlauf von einigen Migrationen feststellen, dass das nicht immer so problemlos klappt. Letztendlich ist mir aber die Deinstallation von Exchange 2007 immer gelungen, dabei musste ich noch folgende zusätzliche Schritte tun.

Start der Exchange 2007 Deinstallation.image

Im folgenden Dialog alle aktiven Elemente deaktivieren.image

Danach startet die Deinstallation in Form eines Readiness Checks und läuft auf die folgenden drei Fehler / Probleme.

image

Fehler 1: Uninstall cannot continue. Database ‘Mailbox Database’: This mailbox database contains one or more mailboxes ..

Fehler 2: Uninstall cannot continue. Database ‘Public Folder Database’: The public folder database …contains the following offline address books(s).
.\Standard-Offlineadressliste

image

Fehler 3: This computer is configured as a source transport server for 1 connector(s) in the organization …

Lösung von Fehler 1

Exchange Management Console / Recipient Configuration / Mailbox – löschen aller vorhandenen Mailboxen. Falls der Administrator eine Mailbox hat, kann diese nicht gelöscht werden – hier ist es notwendig diese zu deaktivieren.

Danach wird über die Exchange Management PowerShell Console die Mailbox Database gelöscht.

Get-MailboxDatabase
Remove-MailboxDatabase -Identity "Mailbox Database"

Lösung von Fehler 2

Die Public Folder Database läßt sich über ADSIEdit löschen:

http://blog.dargel.at/2012/01/19/remove-public-folder-using-adsiedit/

Dazu starten wir ADSIedit mit erweiteren Rechten als Domain Admin und verbinden uns (mit Connect to) zum Configuration Naming Context.

image

von dem wir uns wie im Blog beschrieben zu CN=Public Folder Database durcharbeiten, um diese im Anschluss zu löschen.

image

Lösung von Fehler 3

Exchange Management Console / Organization Configuration / Hub Transport / Send Connectors – löschen aller vorhandenen Connectoren.

Exchange Management Console / Server Configuration / Hub Transport / Receive Connectors – löschen aller vorhandenen Connectoren.

Danach mit Retry den Readyness Check laufen lassen. Danach kann die Deinstallation von Exchange 2007 fortgesetzt werden.

Enjoy it, b!

Windows 10 Gruppenrichtlinien

Mit dem Build 1511 kommen bei mir immer mehr Windows 10 Systeme im SMB Umfeld zu Einsatz. Damit Windows 10 innerhalb einer Windows Domäne sauber konfiguriert werden kann hat Microsoft die entsprechenden ADMX Vorlagen, welche die Grundlagen für die Gruppenrichtlinien (GPOs) darstellen veröffentlicht:

https://www.microsoft.com/en-US/download/details.aspx?id=48257

Für den Build 1511 ist sogar seit dem 17.11.2015 eine aktualisierte Version vorhanden (welche auch abwärtskompatibel ist).

Die Installation der Vorlagen sollte über einen zentralen Speicher (central store – OK, ich verwende das deutsche Wort nicht mehr Winking smile ) erfolgen. Wie dieser angelegt wird ist unter anderem in folgendem Artikel beschrieben:

https://support.microsoft.com/en-us/kb/929841

Im Wesentlichen ist das Vorgehen nicht besonders schwierig:

Herunterladen der aktuellen Templates (hier für Windows 10 Build 1511) unter https://www.microsoft.com/en-US/download/details.aspx?id=48257

Installation des Pakets (Windows10_Version_1511_ADMX.msi) auf einem Server oder PC was letztendlich in einem Verzeichnis C:\Program Files (x86)\Microsoft Group Policy\Windows 10 Version 1511\PolicyDefinitions endet.

Von dort werden die Vorlagen (Templates) in den SysVol Ordner auf den Domain Controller (DC) kopiert:

xcopy "\Program Files (x86)\Microsoft Group Policy\Windows 10 Version 15
11\PolicyDefinitions\*" "%LOGONSERVER%\SysVol\%USERDNSDOMAIN%\Policies\PolicyDef
initions\"

Und die Sprachdateien (Language Files) in einen für die Sprache entsprechenden Unterordner. Ich verwende auf meinen Server generell Englisch, da mir das Übersetzen von Fehlermeldungen zu mühsam ist. Damit ist es bei en-US

xcopy "\Program Files (x86)\Microsoft Group Policy\Windows 10 Version 15
11\PolicyDefinitions\en-US\*" "%LOGONSERVER%\SysVol\%USERDNSDOMAIN%\Policies\Pol
icyDefinitions\en-US\"

Der hier verwendete Xcopy impliziert, dass die Eingabeaufforderung auf Laufwerk C: und elevated (als Administrator) ausgeführt wird.

In SBS Umgebungen eher selten, dafür ein größeren Umgebungen üblich ist der Einsatz von mehreren DCs. Hier sollte, bevor der Store eingerichtet wird, die korrekte Funktion der Replikation geprüft und sichergestellt werden. Die Vorlagen werden dann automatisch zwischen den Domain Controller repliziert.

Beim nächsten Öffnen der Gruppenrichtlinien (Group Policy Managements) werden die neuen ADMX Dateien aus dem Central Policy Store angezogen.

Update 2015-12-02:
Beim Einspielen in einer größeren Umgebung hatte ich prompt das Problem, dass die die DC nicht (mehr) repliziert haben. Aber im Internet ist man ja niemals alleine … hier ein Link zu einer Anleitung mit der sich bei mir der Fehler beheben ließ.

Enjoy it, b!

Wiederbelebung eines Windows Server 2012 R2 SBE, Event 2228 …

… war heute Nacht bei einem Kunden agesagt! Hyper-V Replika und VMs sind eine feine Sache, allerding muss man auch wissen was man damit anstellen kann.

Ausgangssituation (was der Admin meines Kunden wollte)

Da die Installation einer LOB Anwendung am recht neuen SBE stattfinden sollte und der Hersteller der Anwendung sich 100% sicher war, dass dies “kein Problem ist” hatte sich der Admin (nein nicht ich) dazu entschlossen, den bestehenden SBE zu exportieren und modifiziert (andere IP-Adresse in einem anderen Subnetz) als Testsystem zu verwenden.

Dazu hat er folgende Schritte ausgeführt:

# - Hyper-V Host 1
Export-VM –Name sbs.sbsland.local –Path \\mx-whv-2\Temp
# - Hyper-V Host 2
Import-VM –Path 'D:\Temp\sbs.sbsland.local\VirtualMachines\5AE40946-3A98-428E-8C83-081A3C6BD18C.XML'

Danach wurde der SBE auch gestartet, eine Anmeldung war leider nicht möglich – da laut dem Server die Anmeldung nicht authentifiziert werden konnte. Eine lokale Anmeldung mit dem Administrator war jedoch möglich. Ein Blick in das Eventlog und in die Services.msc offenbarte, das ein Start des Active Directories fehlgeschlagen war.

Directory Service, ActiveDirectory_DomainService, 2228

An dieser Stelle klingelte mein Telefon… Confused smile die Testumgebung musst ja fertig werden …

Was war passiert?

Beim Start des ““importieten” SBE wurde vergessen das Netzwerk zu ändern und so waren auf einmal 2 Domain Controller im Netzwerk, von denen der zweite (importierte) den Dienst verweigerte, Ein Blick in sein Eventlog offenbarte das Problem.

image

Mit dem Zeitdruck doch noch das Testsystem fertig zu bekommen, entschlossen wir uns das AD über den DSRM (Directory Services Resource Mode) zu “reparieren”.

Authoritative Restore des AD

Dazu waren folgende Schritte notwendig:

  1. Anmeldung als lokaler Administrator und Konfiguration des Systems für den DSRM
    bcdedit /set safeboot dsrepair

    Neustart des Servers und erneute Anmeldung als lokaler Administrator.

    http://blogs.technet.com/b/activedirectoryua/archive/2008/11/20/how-to-start-in-directory-service-restore-mode-dsrm-in-windows-server-2008-and-windows-server-2008-r2.aspx

  2. Start von ntdsutil und Ausführung der folgenden Schritte
    ntdsutil
    ntdsutil: activate instance ntds
    
    # Active instance set to "ntds". 
    
    ntdsutil: authoritative restore
    
    # die Domain heisst sbsland.local
    
    authoritative restore: restore subtree "CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=sbsland,DC=local"
    
    # Authorative Restore completed successfully.
    
    
    

  3. Danach wurde der DSRM wieder deaktiviert
    bcdedit /deletevalue safeboot
  4. Konfiguration einer neuen IP-Adresse 192.168.32.11
  5. Disable des DHCP-Servers
  6. Neustart des SBE

So, der SBE als Testsystem läuft, hätte der Admin den importierten SBE mit einem isolierten virtuellem Netzwerk (Private Virtual Switch) gestartet, wäre uns das ganze Theater erspart geblieben.

Enjoy it, b!