Leider sind Öffentliche Ordner auch mit Exchange 2010 noch nicht ausgestorben. Im Zuge der Migration von Exchange 2007 nach Exchange 2010 stößt man daher nach wie vor auf sie. Und auf die kleinen Probleme rund um sie.

Im diesem Fall muss die Public Folder Datenbank vom Exchange 2007 Server entfernt werden. Dabei spielt es zunächst keine Rolle ob die Daten zuvor auf einen Exchange Server 2010 repliziert wurden oder ob es tatsächlich die letzte Datenbank ist.

In dieser Installation soll mit Exchange 2010 ganz auf öffentliche Ordner verzichtet werden. Alle Benutzer Ordner wurden daher bereits gelöscht.

Im Ersten Schritt müssen nun die verbleibenden System Ordern, soweit möglich gelöscht werden. Ansonsten verweigert Exchange das Löschen der Datenbank mit dem Hnweis auf noch vorhandene Replikate.

Verschaffen wir uns erstmal einen Überlick über die System Ordner (Exchange 2007 Management Shell):

Get-PublicFolder "\NON_IPM_SUBTREE" -recurse

Nun werden alle Ordner entfernt, welche sich löschen lassen:

Get-PublicFolder "\NON_IPM_SUBTREE" -recurse|remove-publicfolder

Auf Grund der rekursiven Vorgehensweise können nicht alle Ordner in einem Durchgang gelöscht werden. Der Befhel sollte daher noch ein oder 2 mal wiederholt werden bis alle entfernbaren Ordner gelöscht sind:

Nun noch die Datenbank löschen:

Get-PublicFolderDatabase|remove-publicfolderdatabase

Obwohl diese Datenbank auf einem Exchange Server 2007 läuft wurde sie bei der Migration offensichtlich auf irgendeine Art und Weise aktualisiert. Also wechseln zur Exchange 2010 Management Shell. Da die Datenbank in der Exchange 2010 Organisation eigentlich gar nicht auftaucht muss bei der Suche der Server Name des alten Exchange 2007 Server angegeben werden:

Get-PublicFolderDatabase -server gt-exch01

Nun klappt auch das Löschen:

Get-PublicFolderDatabase -server gt-exch01|remove-publicfolderdatabase

Achtung! Diese Methode ist sehr endgültig und sollte nur nach vorheriger Datensicherung angewendet werden!

Andy

Im Rahmen einer Migration kann ein Exchange 2007 Edge Transport Server mit einem Exchange 2010 Hub Transport Server betrieben werden. Der im Folgenden beschriebene Fehler wird mit hoher Wahrscheinlichkeit auch mit einem Exchange 2010 Edge Transport auftreten, da die Ursache in der Hub Transport Rolle liegt.

Zum Fehler: Nach dem ändern der Edge Synchronisation auf den Exchange 2010 Hub Transport Server konnten keine Nachrichten mehr gesendet werden. Der Empfang funktioniert jedoch einwandfrei. Auf dem Exchange 2010 Hub Transport Server füllt sich die Warteschlange des Send Connectors in Richtung Edge Server (SMTP Relay in Active Directory Site to Edge Transport Server) mit der Fehlermeldung „451 4.4.0 DNS query failed“:

Die Anwender erhielten  zudem Benachrichtigungen „Delivery is delayed to these recipients or groups” für die entsprechenden Mails.

Beschreibung der Installation:

·         Exchange 2010 UR2 Standard English, Single Server (MB, HUB, CAS)

o   Auf Windows Server 2008 SP2 Standard English (aktueller Patch Stand)

·         Exchange 2007 SP2 UR 2 Standard English Edge Transport Server

o   Auf Windows Server 2003 R2 SP2 Standard English (aktueller Patch Stand)

Eine Analyse der Transport Logs ergab dass bisher kein Versuch gestartet wurde diese Mails per SMTP zu versenden. Damit konnte der Exchange 2007 Edge Transport als Fehlerquelle nahezu ausgeschlossen werden. Ein Blick in die Connectivity Logs des Hub Transport Servers bestätigte die Fehlermeldung der Warteschlangen:

2010-03-12T13:02:25.714Z,08CC8FFAF64ED566,SMTP,edgesync - duesseldorf to internet,+,SmtpRelayWithinAdSiteToEdge 347ebd04-3856-4d7b-8570-3a5c734c1e46

2010-03-12T13:02:25.714Z,08CC8FFAF64ED566,SMTP,edgesync - duesseldorf to internet,>,Non-existent domain reported by 172.16.2.251

2010-03-12T13:02:25.714Z,08CC8FFAF64ED566,SMTP,edgesync - duesseldorf to internet,-,Messages: 0 Bytes: 0 (The DNS query for ‘SmtpRelayWithinAdSiteToEdge’:'edgesync - duesseldorf to internet’:'347ebd04-3856-4d7b-8570-3a5c734c1e46′ failed with error: InfoDomainNonexistent)

Zugleich fand sich auf hier die Ursache des Problems. Der DNS Server 172.16.2.251 war der Sekundäre DNS Server der IP Konfiguration. Er sollte also gar nicht für die DNS Auflösung herangezogen werden, sofern der Primäre DNS Server antwortet. In diesem Fall konnte der Sekundäre DNS Server die internen Namen auch nicht auflösen. Es war ein nicht bereinigter Eintrag. Allerdings war auch dies ein DNS Server, der grundsätzlich auf die Anfragen geantwortet hat.

Da der Primäre DNS Server aber korrekt auflöst konnte das Problem durch nslookup nicht nachgestellt werden. Der Primäre DNS Server kann alle Server, inklusive Edge Transport, mit FQDN und Shortname auflösen.

Nach dem Entfernen des falschen Eintrags leerte sich dich Warteschlange augenblicklich. Der Fehler konnte durch das erneute Eintragen des falschen DNS Server reproduziert werden. Augenscheinlich verwendet der Transport Service in diesem speziellen Fall die DNS Server nicht in der richtigen Reihenfolge.

Andy

Grundsätzlich sind Snapshots eine feine Sache. Kann man doch schnell und unkompliziert Daten Sichern oder Wiederherstellen oder in Virtuellen Welten mal schnell etwas testen. Seit heute hängt über dieser Annahme ein gewaltiges Fragezeichen. Zumindest Domain Controller können das Anwenden von Snapshots sehr übel nehmen.

In Umgebungen mit mehr als einem DC finden bekanntlich Replikationen statt. Wendet man nun einen alten Snapshot an ist dies für den betroffenen Domain Controller wie eine Wiederherstellung der AD Datenbank einer älteren Version. Grundsätzlich nimmt man nun an hier wird es zu keinen größeren Problem kommen. Durch die „Update Sequence Numbers” (USN) sollten die veralteten Einträge des „wiederhergestellten” DC einfach durch die aktuelleren überschrieben werden.

Leider falsch. Dies kann funktionieren, muss es aber nicht! Der Domain Controller kann diese Prozedur auch als „nicht unterstützte Wiederherstellung” erkennen, was einen NetLogon Dienst im Status „angehalten” und diesen Eintrag im Eventlog nach sich ziehen kann:

ActiveDirectory_DomainService / NTDS General:  Event 2103

The Active Directory database has been restored using an unsupported restoration procedure. Active Directory will be unable to log on users while this condition persists. As a result, the Net Logon service has paused. User Action See previous event logs for details. For more information, see Help and Support Center at http://…

Was auch als “USN Rollback” bezeichnet wird. Zudem finden sich zahlreiche Einträge zum Thema „Replication Lingering Object Problems (Event IDs 1388, 1988, 2042)” in den Logs.

Was war passiert?

Die Umgebung betroffene Umgebung war eine „grüne Wiese” Installation für eine größere Migration bei einem Kunden. Zwar war sie noch nicht produktiv, dennoch steckte schon eine Menge Arbeit in der Einrichtung, inklusive Exchange 2010, PKI, etc.  Zum Zeitpunkt des Vorfalls bestand die Gesamtstruktur aus 1 Root- sowie 5 Child Domains auf Basis Windows Server 2008 R2. Alle DC’s wurden als virtuelle Server in einem Hyper-V 2 Cluster bereitgestellt. Für die Root Domain sowie eine Child Domain existierte bereits ein 2., physikalischer DC auf den alle FSMO Rollen übertragen wurden.

Durch einen „Unfall” ging die LUN verloren, auf der alle Hyper-V Gastsysteme abgespeichert waren. Die LUN konnte aus einem SAN Snapshot wiederhergestellt werden. Dieser Snapshot war jedoch rund 15-30 Minuten alt. Zunächst konnten alle Systeme wieder problemlos gestartet werden. Jedoch waren die Eventlogs voll mit Replikationsproblemen (Event IDs 1388, 1988, 2042). Im Falle des virtuellen DC der Root Domain erschien auch der Event 2103. Zudem war der Dienst „NetLogon” im Zustand „paused”.

Leider finden sich auf Anhieb nicht wirklich viele Informationen in der Microsoft Knowledge Base oder einschlägigen Foren. Der allgemeine Tenor zum Event 2103 lautete: AD auf dem DC entfernen und neu installieren. Sicher eine Lösung, aber nicht unbedingt eine befriedigende.

Und an dieser Stelle gilt unser Gruß und Dank Jan Kappen, der unter Einsatz von Blut Schweiß und reichlich Kaffee dieses Problem bereits mit dem Microsoft Support gelöst und freundlicherweise dokumentiert hat!

Hier die Schritte in der Kurzfassung:

Beseitigung Event 2103:

• HKLM\System\CurrentControlSet\Services\NTDS\Parameters
  • “Dsa Not Writable” von 4 auf 0 setzen
  • REG_DWORD “Ignore USN Rollback” anlegen und auf 0 setzen
• Server neu starten (NetLogon sollte nun laufen)
• Replikation wieder aktivieren:
  • repadmin /options “Servername” -DISABLE_OUTBOUND_REPL
  • repadmin /options “Servername” -DISABLE_INBOUND_REPL

Nun waren nur noch ein par “Lingering Objects” übrig welche die Replikation blockierten. Diese Objekte können ebenfalls mit dem „repadmin” entfernet werden. Dazu gibt es aber diverse Anleitungen so dass ich es nicht näher beschreibe.

Da unser Snapshot nur 15-30 Minuten alt war mussten wir kein DC Computer Konto zurücksetzen. Dies hat Jan aber auch gut beschrieben.

Viel Erfolg!

Andy

Quelle: Hyper-V, ADS-Controller und angewendete Snapshots [Update]

Ein Server Core stellt für die meisten GUI verwöhnten Windows Administratoren eine gewisse Herausforderung dar. Eine davon ist das Initialisieren neuer Disks mit DISKPART, zumal sich hier auch das Verhalten gegenüber Windows Server 2003 verändert hat. So ist eine neue Disk zunächst „Read Only”.

Dieses Attribut verhindert nach dem Onlinenehmen der Disk jede weitere Bearbeitung. Es kann jedoch recht einfach entfernt werden. Dazu habe ich einmal die üblichen Befehle zum Einrichten einer neuen Disk aufgelistet:

• RESCAN (sofern die Disk im laufenden Betrieb angehängt wurde)
• LIST DISK
• SELECT DISK x (hier besonders aufpassen das es die Richtige ist. )
• ONLINE
• ATTRIBUTE DISK CLEAR READONLY
• CONVERT GPT (optional)
• CREATE PARTITION PRIMRAY
• FORMAT FS=NTFS QUICK LABEL=”<label>”
• ASSIGN LETTER=<X>

Viel Erfolg,

Andy

Es gibt sicherlich diverse Anleitungen zur Migration von LCS 2005 SP1 nach OCS 2007 R2. Jedoch sind die meisten davon an irgendeiner Stelle etwas unverständlich oder uneindeutig. Da eine solche Migration wenig Spielraum für Fehler lässt habe ich sie im Lab durchgespielt und dokumentiert. Ich habe dabei den Weg der Koexistenz gewählt, da dieser den geringsten Einfluss auf laufende Umgebungen hat und daher am häufigsten angewendet wird.

Lab Setup (Hyper-V V2):

• DC Windows Server 2003 R2 x86
  • AD 2003, Forest und Domain 2003 native
• LCS 2005 SP1 SE auf Windows Server 2003 R2 x86
• Communicator 2005 auf Windows XP Pro x86 (2x)
• Communicator 2007 R2 auf Windows XP Pro x86
• Windows Server 2008 SP2 x64 für OCS 2007 R2 SE

Voraussetzungen:

• Active Directory mind. Version Windows Server 2003, Forest und Domain im 2003 native Mode
• LCS 2005 SP mit den Updates KB911996 und KB921543 (in dieser Reihenfolge installieren!)
• Einen Benutzer mit folgenden Privilegien:
  • Enterprise Admin
  • Schema Admin
  • Domain Admin (in Multi Domain Umgebung)
  • RTCDomainServerAdmin

Durchführung:

Schritt 1:

Alle LCS Dienste stoppen

Schritt 2:

Migration der Global Settings aus dem System Container in den Configuration Container. Dieser Schritt verschiebt die Einstellungen des LCS/OCS im Active Directory. Er ist derzeit optional, der bisherige Speicherort ist jedoch nicht optimal und wird wahrscheinlich von künftigen Versionen nicht mehr unterstützt. (mehr dazu siehe technische Referenz)

Wichtig! dieser Schritt MUSS vor dem Schema Update auf Version 1008 (OCS 2007 R2) durchgeführt werden! Danach funktioniert das Tool nicht mehr und OCS muss komplett neu installiert werden (DB Export, AD Bereinigung, etc.)!

• Installation von MigrateOCS.msi auf einem x86 Server (in diesem Fall der LCS, macht die Sache einfacher)
• Ausführen der folgenden Befehle (standard Pfad zum Script ist C:\MigrateOCS):
  • cscript MigrateOcsGlobalSettings.vbs /Action:MigrateGlobalSettingsTree
  • cscript MigrateOcsGlobalSettings.vbs /Action:MigrateGlobalSettingsProperties
• Nun muss ForestPrep und DomainPrep für den neuen Speicherort der Konfiguration wiederholt werden. Diese Befehle müssen auf dem LCS Server ausgeführt werden und funktionieren NUR wenn die beiden Updates installiert wurden! Sie dürfen zudem nicht aus der GUI gestartet werden! (standard Pfad: c:\program files\common files\microsoft LC 2005)
  • LcsCmd /Forest /Action:ForestPrep /global:configuration
  • LcsCmd /Domain /Action:DomainPrep
• Im Anschluss werden Server und User Objekte neu Referenziert und die alte Konfiguration wird bereinigt:
  • cscript MigrateOcsGlobalSettings.vbs /Action:MigrateServerDnReferences /SearchBaseDN:dc=domain,dc=local
  • cscript MigrateOcsGlobalSettings.vbs /Action:MigrateUserDnReferences /SearchBaseDN:dc=domain,dc=local
  • cscript MigrateOcsGlobalSettings.vbs /Action:DeleteSystemGlobalSettingsTree

Hinweis: Je nach Geschwindigkeit und Anzahl von Replikationsverbindungen sollte zwischen den Ausführungen eine ausreichende Zeit gewartet werden! Zudem kann es passieren dass einzelne Schritte mehrfach ausgeführt werden müssen. Dies meldet das Script in seiner Ausgabe!

Schritt 3:

Alle LCS Server neu starten.

Nun sollten alle LCS Clients wieder normal funktionieren.

Schritt 4:

Installation OCS 2007 R2

Die Installation folgt nun der üblichen Vorgehensweise:

• AD Vorbereitung
  • SchemaPrep
  • ForestPrep
  • DomainPrep
• Deployment (siehe auch hier: OCS 2007 und KB974571)

Die DNS Konfiguration benötigt nun noch eine gewisse Planung. Grundsätzlich kann und sollte hier der neue OCS 2007 R2 Pool als Ziel des SRV Eintrags vorgesehen werden. Er wird den Client authentifizieren und an den richtigen (LCS) Front End Server weiterleiten.

Hinweis: Während der Migration ist die Reihenfolge beim Update des Clients wichtig für einen nahtlosen Übergang:

• Während des Verschiebens der Benutzer von LCS nach OCS kann nur der LCS Client verwendet werden.
  • Der Communicator 2007 R2 ist nicht mit dem LCS Server kompatibel!
  • Der LCS Client kann sich mit dem OCS 2007 R2 Front End Server verbinden, jedoch steht “Enhanced Prensence” nicht zur Verfügung.
• “Enhanced Prensence” darf erst aktiviert werden wenn sichergestellt ist dass der Benutzer nur noch Clients ab Version 2007 verwendet. Dies gillt auch für Communicator Web Access oder den Communicator Mobile!
  • Sobald “Enhanced Prensence” aktiviert und ein Client ab Version 2007 erfolgreich angemeldet wurde, können sich ältere Clients nicht mehr verbinden.

Sieh auch: Migrating from LCS 2005 SP1 to OCS 2007 R2 - which client can you use when?

Viel Glück & Erfolg!

Andy

Nach dem Hotfix KB974571 hat es diverse Probleme im Zusammenhang mit LCS/OCS Eval Versionenen gegeben. Nun ist ein Fix namens OCSASNfix.exe erscheinen. Er kann über die Seite des Hotfixes bezogen werden: http://support.microsoft.com/kb/974571 (direkter Download Link hier klicken). Bei bereits installieren Systemen ist dies auch problemlos möglich. Etwas komplizierter wird jedoch eine neue OCS Installation.

Grundsätzlich kann man natürlich den Hotfix KB974571 auch erst nach der Installation von OCS installieren. Möchte man dies nicht, oder ist er bereits im Windows installiert, wird es bei der Installation von OCS R2 spannend. Der Patch OCSASNfix.exe wirkt erst wenn die OCS Binaries bereits installiert ist. Die Installation scheitert jedoch bei der Aktivierung des Standard Servers mit einer obskuren Meldung, man solle doch Datum und Uhrzeit des Servers prüfen. Dies gilt interessanterweise auch für die nicht Eval Version der OCS Installationsquellen:

Failure: [0xC3EC796C] One or more errors occurred during execution of the wizard; the wizard was unable to complete successfully. Please check the log file for more information.

Failure: [0xC3EC78D8] Failed to read the Office Communications Server version information. This can happen if the computer clock is not set to correct date and time.

Nun muss man einfach die Nerven behalten und folgende Reihenfolge bei der Installation einhalten:

• Installation des Standard Server mit dem Assistenten (wird bei der Aktivierung scheitern)
• OCSASNfix.exe ausführen (wird zwar melden dass keine Eval Version gefunden wurde, ändert aber wohl doch irgendwas)
• Den Installationsassistenten noch einmal ausführen. Er mit der Aktivierung fortfahren, welche jetzt auch gelinngen sollte

Andy

Das Microsoft Deployment Toolkit 2010 eröffnet jedem kleinen und mittleren Unternehmen einen kostengünstigen Einstieg in automatisiertes, standardisiertes  und rationelles Client Deployment. Auch wenn der Fokus dieses Programms eindeutig auf dem Deployment von Windows 7 bzw. der Migration dazu hin liegt, kann auch Windows XP installiert werden.

Neben einigen, designbedingten Einschränkungen bei der Installation von XP gibt es jedoch zumindest ein gravierendes Problem: Mit den vorhandenen Skripts lässt sich kein einfacher Hardware Austausch bewerkstelligen, wenn Windows XP auf den neuen System installiert sein soll. In diesem Fall funktioniert die Übernahme von lokalen Profilen mit Hilfe von USMT nicht. Mit wenigen Handgriffen lässt sich jedoch ein Workaround erstellen.

Update: Bitte beachten Sie auch den Hinweis von Maik in den Kommentaren!

Bei unseren Tests stellte sich rasch heraus dass die MDT Scripts zum Erstellen der User State Sicherungen USMT 4 benutzt. Beim Versuch diese Daten auf einem neu installierten XP wiederherzustellen, scheiterte dies. Die Skripte Benutzen in diesem Fall automatisch USMT3, da USMT4 unter XP nur den User State sichern, nicht aber wiederherstellen kann. Das Script endet mit der Fehlermeldung “no user state folder (USMT3)”. Zudem wären die USMT3 Dateien im AIK für Windows 7 gar nicht vorhanden.

Als Workaround kann nun USMT 3 für Erstellung der User States verwendet werden. Dazu sind folgende Schritte notwendig:

• Download von USMT 3.01
• Speichern der beiden MSI Pakete (x86 und x64) in den jeweiligen Ordnern im <Deployment Share>\Tools Verzeichnis
• Kopieren der Script Datei ZTIUserState.wsf, z.B. in ZTIUserStateUSMT3.wsf
• Ändern der kopierten Script Datei (rot markierte Stellen einfügen bzw. ändern):

Class Header anpassen:

‘//—————————————————————————-
‘// Main Class
‘//—————————————————————————-

Class ZTIUserStateUSMT3

Im weiteren Verlauf USMT3 erzwingen, egal was vom Sctipt ermittelt wird:

‘ Deterine if we are going to run USM3 or USMT4
If Ucase(oEnvironment.Item(”USMT3″)) = “YES” and Left(oEnvironment.Item(”OSCURRENTVERSION”),3) < “6.1″ then
sUSMTVersion = “USMT3″
Else

If Left(oEnvironment.Item(”ImageBuild”),3) < “6.0″ and oENvironment.Item(”DeploymentType”) <> “REPLACE” and oEnvironment.Item(”DeploymentMethod”) <> “SCCM” Then
oLogging.CreateEntry “Windows XP is being deployed, assuming USMT 3″, LogTypeInfo
sUSMTVersion = “USMT3″
Else
sScanState=”scanstate.exe”
iRetVal = oUtility.FindFile(sScanState, sFoundScanState)
If iRetVal = Success then
If Left(oFSO.GetFileVersion(sFoundScanState),3) = “6.1″ then
oLogging.CreateEntry “Found USMT 4 executables. Using USMT 4″, LogTypeInfo
sUSMTVersion = “USMT4″
Else
oLogging.CreateEntry “USMT 4 executables were not found, using USMT 3″, LogTypeInfo
sUSMTVersion = “USMT3″
End if
Else
oLogging.CreateEntry “Executables were not found, assuming USMT 3 installer”, LogTypeInfo
sUSMTVersion = “USMT3″
End if

End If
End If

sUSMTVersion = “USMT3″

‘//—————————————————————————-
‘// See what we need to do
‘//—————————————————————————-

• Nun eine neue  Tasksequenz für das Client Replacement erstellen und im Task “Capture User State” den Commandline Befehl auf das zuvor geänderte Skript ändern:

cscript.exe “%SCRIPTROOT%\ZTIUserStateUSMT3.wsf” /capture

Nun kann der Client Replacement Task wie gewohnt ausgeführt und beim Deployment von Windows XP der User State zurückgeschrieben werden.

Dieses Script funktioniert natürlich nicht mehr wenn zu Windows 7 hin migriert werden soll! Dann muss der Replacement unverändert ausgeführt werden.

Andy.

Ganz aktuell ist die Meldung über ein Problem, welches durch den Hotfix KB974571 in Zusammenhang mit dem Live Communications Server und Office Communications Server ausgelößt wird. Nach der Installation befindet sich der LCS / OCS Server im Zustand einer abgelaufenen Evaluierungsphase und startet nicht mehr.

UPDATE: Das Problem betrifft auch den Client! Auch hier darf der Hotfix derzeit nicht installiert werden! Zumindest auf dem Client konnte eine Deinstallation des Hotfix erfolgreich durchgeführt werden und hat das Problem gelöst.

Vom Fehler betroffen sind alle Versionen des LCS 2005, OCS 2007 und OCS 2007 R2. Derzeit ist kein Patch veröffentlicht, so dass die Installation des Hotfixes auf betroffenen Servern verhindert werden sollte! Ob eine Deinstallation erfolgreich durchgeführt werden kann ist derzeit nicht bekannt.

Andy

Quelle: http://blogs.technet.com/dodeitte/archive/2009/10/13/do-not-apply-kb974571-to-lcs-ocs-servers.aspx

Exchange 2007 Service Pack 2 ist verfügbar. Bei der Installation in meiner Testumgebung hat sich allerdings ein kleiner Fehler offenbart. Beim Versuch das Service Pack zu installieren brach der Rediness Check mit folgender Begründung ab:

[03.10.2009 13:57:31] [1] [ERROR] The Active Directory Schema must be modified and this user account has insufficient permissions. It must be a member of both the ‘Schema Admins’ and ‘Enterprise Admins’ groups.
[03.10.2009 13:57:31] [1] [ERROR] Global updates need to be made to Active Directory, and this user account is not a member of the ‘Enterprise Admins’ group.

Meine Testumgebung besteht aus einer einzelnen Active Directory Domain in einem einzelnen Active Directory Forest.  Der für das Upate verwendete Benutzer ist Mitglied in den folgenden Gruppen:

• Domain-Admins
• Schema-Admins
• Exchange Organization Adminstrators

In meinen Augen sollte dies die vollständige Macht über meine Testumgebung erlauben. Besonders die Anforderung an die Mitgliedschaft in der “Enterprise Admins” Gruppe machte mich stutzig, da diese in meiner single Domain die gleiche Verschachtelung in die Gruppe “Builtin\Administrators” hat wie die “Domain Admins” Gruppe.

Ich habe dann einmal den vordefinierten “Administrator” verwendet. Dieses Konto wurde vom Rediness Check akzeptiert. Schließlich war es die direkte Mitgliedschaft in der Gruppe “Builtin\Administrators” welche den Ausschlag über Erfolg oder Misserfolg des Rediness Checks gibt. Anscheinend funktioniert beim Rediness Check die Prüfung verschachtelter Gruppenmitgliedschaften nicht richtig.

Andy

Unter Hyper-V kann es auf Windows 2003 Domain Controllern zu regelmäßigen Eventlog Einträgen kommen, welche augenscheinlich keine Ursache haben. So wird alle 10 Minuten folgender Event protokolliert:

ID: 1054
Source: Userenv
Version: 5.2
Symbolic Name: EVENT_FAILED_DSNAME
Message: Windows cannot obtain the domain controller name for your computer
network. (An unexpected network error occurred). Group Policy processing aborted.

Ähnliche Probleme treten z.B. bei multihomed Servern, DNS Problemen oder AMD Mehrprozessorsystemen ohne entsprechende Treiber auf.

Diese Ursachen konnten jedoch ausgeschlossen werden. Da sich der Event durch ein manuelles Update der Gruppenrichtlinien (GPUPDATE) nicht erzwingen lies lag die Vermutung nahe, dass die Ursachen weder im Netzwerk noch bei DNS zu suchen war. Blieb nur ein Problem mit dem System Timer. Die Option /usepmtimer war schnell in die boot.ini eingefügt und getestet und hat sich als Lösung erwiesen.

Siehe auch KB895980

Andy