No Minimal Required Number of Suitable Directory Servers Found in Forest
Ausgangssituation
Nach einem Exchange 2013 Crash dank ESXI 6.0 musste ich eine Recovery-Installation durchführen.
Während der Neu-Installation des Exchange 2013 brach diese jedoch immer wieder mit Folgender Fehlermeldung ab:
Prozess Microsoft.Exchange.Directory.TopologyService.exe (PID=4772) Gesamtstruktur xxxxx.local. Fehler bei der Topologieerkennung, Fehlerdetails No Minimal Required Number of Suitable Directory Servers Found in Forest xxxxx.local Site Standardname-des-ersten-Standorts and connected Sites..
Die Domäne hatte schon immer nur einen Domain-Controller, von daher war die Meldung erstmal unverständlich.
Verschiedene Seiten und Blogs empfehlen in diesem Fall den Wert
MinSuitableServer = “1” in in der Microsoft.Exchange.Directory.TopologyService.exe.config zu ändern. Aber auch das brachte keine Veränderung.
Letztendlich habe ich einen zweiten DC installiert – aber auch dies brachte keine Veränderung. Die Fehlermeldung blieb.
Die Lösung
Zielführend war folgende Seite:
Der Zusammenhang war zwar ein anderer, aber das beschriebene Problem war das gleiche: In der Default Domain Controllers Policy hat unter
Computer Configuration ->Windows Settings -> Security Settings ->Local Policies -> User Rights Assignment beim “Mange auditing and security log” der Eintrag “Exchange Servers” gefehlt (Warum auch immer in diesem Fall….)
Das heißt, der Exchange-Server hatte nicht das Recht auf die Auditing und Security Logs des Domain-Controllers zuzugreifen und das Installationsprogramm interpretierte dies mit der Meldung, dass nicht genügend Domain-Controller verfügbar waren – was natürlich kompletter Quatsch war.
Nachdem das korrigiert war, lief die Installation ohne Probleme durch.
Raid Erweiterung auf einem HP Proliant Server unter ESXi 6.0
Ausgangssituation
Auf einem HP Proliant Server mit ESXi 6.0 wird der freie Platz im Datastore knapp. Man fügt also zusätzliche Festplatten hinzu und möchte diese Platten jetzt dem Raid-Array und dann dem logischen Laufwerk hinzufügen ohne Downtime.
Durchführung: Man schaltet sich per SSH auf den ESXi Host und nutzt das Kommando
/opt/hp/hpssacli/bin/hpssaDoof ist nur wenn dieses Programm nicht da ist – der Server wurde aber mit einem originalen HP ISO für VMWare installiert…
Lösung
Das notwendige Programm liegt bei ESXI 6.0.0 524934 unter
/opt/smartstorageadmin/ssacli/bin/und unterstützt den interaktiven Modus nicht mehr.
Somit muss man jetzt eingeben:
ssacli ctrl all show config
und bekommt in meinem Fall (4x 900 GB mit Raid 10 und 2 zwei neuen Platten)
[root@esx01:/opt/smartstorageadmin/ssacli/bin] ./ssacli ctrl all show config
Smart Array P440ar in Slot 0 (Embedded) (sn: XXXXXXXXX)
Port Name: 1I
Port Name: 2I
Internal Drive Cage at Port 1I, Box 6, OK
Internal Drive Cage at Port 2I, Box 6, OK
Array A (SAS, Unused Space: 0 MB)
logicaldrive 1 (1.6 TB, RAID 1+0, OK)
physicaldrive 2I:6:1 (port 2I:box 6:bay 1, SAS HDD, 900 GB, OK)
physicaldrive 2I:6:2 (port 2I:box 6:bay 2, SAS HDD, 900 GB, OK)
physicaldrive 2I:6:3 (port 2I:box 6:bay 3, SAS HDD, 900 GB, OK)
physicaldrive 2I:6:4 (port 2I:box 6:bay 4, SAS HDD, 900 GB, OK)
Unassigned
physicaldrive 1I:6:5 (port 1I:box 6:bay 5, SAS HDD, 900 GB, OK)
physicaldrive 1I:6:6 (port 1I:box 6:bay 6, SAS HDD, 900 GB, OK)
und dort sind auch die beiden neuen Festplatten. Diese fügt man jetzt hinzu mit:
ssacli ctrl slot=0 array A add drives=allunassigned
Dieser Vorang dauer jetzt sehr lange…..bei mir ca 8 Stunden.
Mit ssacli ctrl all show config kann man den Vorang beobachen:
....
Array A (SAS, Unused Space: 1716905 MB)
logicaldrive 1 (1.6 TB, RAID 1+0, Transforming, 2.66% complete)
und wenn es fertig ist:
Smart Array P440ar in Slot 0 (Embedded) (sn: XXXXXXXXXXX)
Port Name: 1I
Port Name: 2I
Internal Drive Cage at Port 1I, Box 6, OK
Internal Drive Cage at Port 2I, Box 6, OK
Array A (SAS, Unused Space: 1716905 MB)
logicaldrive 1 (1.6 TB, RAID 1+0, OK)
physicaldrive 1I:6:5 (port 1I:box 6:bay 5, SAS HDD, 900 GB, OK)
physicaldrive 1I:6:6 (port 1I:box 6:bay 6, SAS HDD, 900 GB, OK)
physicaldrive 2I:6:1 (port 2I:box 6:bay 1, SAS HDD, 900 GB, OK)
physicaldrive 2I:6:2 (port 2I:box 6:bay 2, SAS HDD, 900 GB, OK)
physicaldrive 2I:6:3 (port 2I:box 6:bay 3, SAS HDD, 900 GB, OK)
physicaldrive 2I:6:4 (port 2I:box 6:bay 4, SAS HDD, 900 GB, OK)
Jetzt muss man das logische Laufwerk erweitern mit:
ssacli ctrl slot=0 logicaldrive 1 modify size=max forced
Die Erweiterung kann man dann mit kontrollieren mit ssacli ctrl all show config
Smart Array P440ar in Slot 0 (Embedded) (sn: XXXXXXXXXXXXX)
Port Name: 1I
Port Name: 2I
Internal Drive Cage at Port 1I, Box 6, OK
Internal Drive Cage at Port 2I, Box 6, OK
Array A (SAS, Unused Space: 0 MB)
logicaldrive 1 (2.5 TB, RAID 1+0, OK)
physicaldrive 1I:6:5 (port 1I:box 6:bay 5, SAS HDD, 900 GB, OK)
physicaldrive 1I:6:6 (port 1I:box 6:bay 6, SAS HDD, 900 GB, OK)
physicaldrive 2I:6:1 (port 2I:box 6:bay 1, SAS HDD, 900 GB, OK)
physicaldrive 2I:6:2 (port 2I:box 6:bay 2, SAS HDD, 900 GB, OK)
physicaldrive 2I:6:3 (port 2I:box 6:bay 3, SAS HDD, 900 GB, OK)
physicaldrive 2I:6:4 (port 2I:box 6:bay 4, SAS HDD, 900 GB, OK)
Jetzt geht es zurück in den vCenter Client wo man den Datastore erweitert kann:
Fertig!
Schattenkopien sind kein Backup
Bei der aktuellen Diskussion über geeignete Schutzmaßnahmen argumentieren viele Admins, dass Sie ja Schattenkopien auf Ihren Fileservern einsetzen.
Warum man Schattenkopien nicht als zuverlässiges Backup einschätzen sollte:
Bei dem Kunden waren die Schattenkopien mit mehr als 40 GB weg….
WSUS Datenbank auf Windows 2012 R2 neu erzeugen
Ich hatte neulich den Fall, dass die WSUS Datenbank auf einem Windows 2012 R2 Server korrupt war und daher der WSUS Dienst nicht mehr funktionierte.
Die naheliegende Idee, WSUS Server deinstallieren und wieder neu zu installieren brachte kein Erfolg, da die notwendige Datenbank
C:\Windows\WID\Data\SUSDB.mdf
durch die Deinstallation NICHT entfernt wird. D.h. nach der Neuinstallation des WSUS ist man an der gleichen Stelle.
Wenn man jetzt die o.g. Datebank einfach löscht, so bekommt man bei der Neuinstallation Fehlermeldungen.
In dem dazugehörigen Logfile steht dann auch die Ursache:
2016-06-02 11:37:26 Configuring WID database... 2016-06-02 11:37:26 Configuring the database... 2016-06-02 11:37:26 Establishing DB connection... 2016-06-02 11:37:26 Checking to see if database exists... 2016-06-02 11:37:26 Database exists 2016-06-02 11:37:26 Switching database to single user mode... 2016-06-02 11:37:27 System.Data.SqlClient.SqlException (0x80131904): Die physische Datei 'C:\Windows\WID\Data\SUSDB.mdf' kann nicht ge”ffnet werden. Betriebssystemfehler 2: '2(Das System kann die angegebene Datei nicht finden.)'. Die physische Datei 'C:\Windows\WID\Data\SUSDB.mdf' kann nicht ge”ffnet werden. Betriebssystemfehler 2: '2(Das System kann die angegebene Datei nicht finden.)'. Die SUSDB-Datenbank konnte nicht neu gestartet werden. Der vorherige Status wird wiederhergestellt. Fehler bei der ALTER DATABASE-Anweisung. Dateiaktivierungsfehler. Der physische Dateiname 'C:\Windows\WID\Data\SUSDB_log.ldf' ist m”glicherweise falsch. Dateiaktivierungsfehler. Der physische Dateiname 'C:\Windows\WID\Data\SUSDB_log.ldf' ist m”glicherweise falsch. bei Microsoft.UpdateServices.DatabaseAccess.DBConnection.DrainObsoleteConnections(SqlException e) bei Microsoft.UpdateServices.DatabaseAccess.DBConnection.ExecuteCommandNoResult() bei Microsoft.UpdateServices.Administration.ConfigureDB.ConnectToDB() bei Microsoft.UpdateServices.Administration.ConfigureDB.Configure() bei Microsoft.UpdateServices.Administration.ConfigureDB.Run(String instanceName, Action`1 logWriter, Boolean contentLocal) bei Microsoft.UpdateServices.Administration.PostInstall.Run() bei Microsoft.UpdateServices.Administration.PostInstall.Execute(String[] arguments) ClientConnectionId:5c9b6d98-4cbe-47eb-8465-f7fde71f8c4f Fehlernummer (Error Number):5120,Status (State):101,Klasse (Class):16 Schwerwiegender Fehler: Die physische Datei 'C:\Windows\WID\Data\SUSDB.mdf' kann nicht ge”ffnet werden. Betriebssystemfehler 2: '2(Das System kann die angegebene Datei nicht finden.)'. Die physische Datei 'C:\Windows\WID\Data\SUSDB.mdf' kann nicht ge”ffnet werden. Betriebssystemfehler 2: '2(Das System kann die angegebene Datei nicht finden.)'. Die SUSDB-Datenbank konnte nicht neu gestartet werden. Der vorherige Status wird wiederhergestellt. Fehler bei der ALTER DATABASE-Anweisung. Dateiaktivierungsfehler. Der physische Dateiname 'C:\Windows\WID\Data\SUSDB_log.ldf' ist m”glicherweise falsch. Dateiaktivierungsfehler. Der physische Dateiname 'C:\Windows\WID\Data\SUSDB_log.ldf' ist m”glicherweise falsch.
D.h. die eigentliche Konfiguration für den WSUS wurde wieder übernommen und jetzt fehlen natürlich die (gelöschten) Datenbanken.
Wie bekommet man also des WSUS dazu die Datenbank komplett neu zu erstellen?
- Man benötigt das MS SQL 2012 Management Studio Express, was man unter https://www.microsoft.com/de-de/download/details.aspx?id=29062 herunterladen kann.
- Das Programm installiet man und startet es explizit als Administrator!
- Man verbindet sich zu \\.\pipe\Microsoft##WID\tsql\query
- Dort löscht man dann die WSUS Datebank:
Wenn der Eintrag für die Datenbank gelöscht ist, startet man die WSUS Installation auf dem Server erneut – und siehe da – er startet die Komplette Konfiguration des WSUS erneut und legt die Datenbank komplett neu und sauber an!
Quellen:
https://en.wikipedia.org/wiki/Windows_Internal_Database
Office öffnet keine Dateien von Netzwerklaufwerken oder Onedrive
Auf einem Lenovo Thinkpad T450s mit Windows 10 hatte ich neulich folgendes Problem:
Sämtliche Office 2016 Programm konnten keine Dateien mehr öffnen wenn diese auf einem Netzwerk-Laufwerk oder auch OneDrive gespeichert waren. Nach dem Starten des Programms stürzte dieses sofort wieder ab und das Dokument wurde geschlossen.
Kopierte man die Datei jedoch auf die lokale Festplatte des Computers, konnte man diese auch normal öffnen.
Im Ereignisprotokoll stand jeweils:
Ereignis 1000, Application Error Name der fehlerhaften Anwendung: WINWORD.EXE, Version: 16.0.6366.2056, Zeitstempel: 0x568f31f0 Name des fehlerhaften Moduls: ntdll.dll, Version: 10.0.10586.20, Zeitstempel: 0x5654262a Ausnahmecode: 0xc0000005 Fehleroffset: 0x0003ef53 ID des fehlerhaften Prozesses: 0x23b0 Startzeit der fehlerhaften Anwendung: 0x01d15b37ff9e51f1 Pfad der fehlerhaften Anwendung: C:\Program Files (x86)\Microsoft Office\Root\Office16\WINWORD.EXE Pfad des fehlerhaften Moduls: C:\WINDOWS\SYSTEM32\ntdll.dll Berichtskennung: 3de9f46e-c72b-11e5-9ccc-68f728db1328 Vollständiger Name des fehlerhaften Pakets: Anwendungs-ID, die relativ zum fehlerhaften Paket ist:
Folgende Maßnahmen waren ohne Erfolg
- Office Reparatur
- Office De- und Neu-Installation
- Installation aller aktueller Windows-Updates
- Installation aller aktueller Office Updates
Ziel weisend für die Fehlerbehebung war schließlich folgender Microsoft KB Eintrag für Office 2013:
https://support.microsoft.com/de-de/kb/2813143
Und in der Tat war der Schuldige tatsächlich eine ältere Version der Displaylink-Software.
Nach der Deinstallation funktionierte Office 2016 wieder normal.
Fehlermeldung: Application Manager kann nicht ausgeführt werden.
Seit dem Update auf die Version 5.0.142.5 des Autodesk Application Manager erhalten die Benutzer nach dem Login folgende Fehlermeldung:
Fehlermeldung: Application Manager kann nicht ausgeführt werden.
Autodesk hat hierzu einen Eintrag in ihrer Knowledgebase mit einer vermeintlichen Lösung: http://knowledge.autodesk.com/de/support/autocad/troubleshooting/caas/sfdcarticles/sfdcarticles/DEU/Error-Unable-to-run-Application-Manager.html
Den Hinweis, man möge doch die Benutzerkontensteuerung doch einfach ausschalten kann aber nicht wirklich deren Ernst sein – oder ? Auch der Hinweis, man möge das Programm doch einfach als Administrator starten hilft einem nicht weiter, wenn die User eben dieses Recht nicht haben.
Das Problem ist nun aber, dass Autodesk dieses Programm beim Login jedes Users starten lässt und somit erhalten die User jedes mal eine schöne Fehlermeldung.
Im Programm selber kann man unter Einstellungen angeben, dass es bei Anmeldung am Computer nicht automatisch gestartet werden soll – aber auch das funktioniert nicht.
Meine Lösung: Ich schmeiße das Programm aus den Autostart.
Hierzu muss der Eintrag ADSKAppManager in der Registry der Rechner im Pfad
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run]
entfernen. Das kann man entweder lokal machen oder per Gruppenrichtlinie.
Danach haben die Benutzer Ruhe und die Admins können das Programm wenn nötig manuell starten.
Neueste Kommentare