Guten Morgen Com!

Es geht um eine bestehende Windows Domain mit Server 2016 Standard als DC. In die bestehende Domäne haben wir einen Essentials Server als Mitgliedsserver eingebunden. Nun "meckert" der Essentials Server, das sei nicht lizenzkonform - aber die Anleitung für die Eingliederung als Mitgliedsserver stammt von der Microsoft Seite.

Ich darf an dieser Stelle noch keine Bilder und Links einfügen... mein Konto ist noch nicht geprüft...
Ich hoffe, die Leerzeichenschreibweise wird nicht geblockt. Hier die Screenshots
ht tps: //www. dropbox. com/sh/g12hg70bz6sxa8f/AABYR1lXb1W3wqFz5P3CPytKa?dl=0

Das Problem nun ist: Der Essentials Server ist jetzt zum 2. Mal ohne erkennbaren Grund (Stromausfall o. ä.) aus gewesen - die Protokolle sind auch sauber. Ich vermute/befürchte also, dass sich die Maschine selbst ausgeschaltet hat.

Wie ist denn nun tatsächlich der Lizenz-Status? Ist das so tatsächlich nicht erlaubt? Muss ich für den Server eine andere Lizenz organisieren? Kann es sein, dass sich der Server tatsächlich wegen des Lizenzproblems selbst abschaltet?

Vielen Dank für eure Hilfe.

Henning

Hallo,

aktuell habe ich irgendwie Probleme meine Terminalserverlizenzen zu erweitern. Ich hatte aktuell 140 Lizenzen "Device" installiert. Zu diesen sind nun noch 30 weitere hinzugekommen. Im VLSC werden diese auch gemeinsam als 170 Stück angezeigt. Jedoch lässt mich der Wizard die weiteren 30 nicht installieren? Muss ich die aktuellen 140 löschen und dann komplett als 170 installieren?

Danke für die Hilfe.

Hallo Miteinander

Da ich auf einem unserer Citrix Terminal Server fehlende Ordner und Dateien im Default Profil gefunden habe (Nur noch Appdata Ordner und einige ntuser Dateien vorhanden), möchte ich dieses korrupte Profil nun gern erneuern. Bewusst wurde mir dies, nachdem sich neue User welche sich das erste Mal anmeldeten gleich wieder rausgeschmissen wurden aus der Session, und ich nachher auf dem Servergespeicherten Profil sah, dass dort einiges fehlte. 

Ich habe zur Default Profilerneuerung von MS nur diesen Link gefunden:

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

Es muss doch aber einen Weg geben, das irgendwie zu lösen mit einer anderen Methode? Bei einem neu aufgesetzten Server mag diese Methode ja ideal sein, aber in meinem Fall läuft der Server bereits seit einigen Jahren und ich kann/will ihn nicht einfach resetten....

Die nicht unterstützte Methode, einfach den Inhalt von einem funktionierenden Profil in den Default Ordner zu kopieren, kenne ich auch. Es wurde aber von Microsoft strengstens abgeraten, dies zu tun. Die Folgeprobleme dieser Methode sind mir ebenfalls bekannt.

Weiss hier vielleicht jemand mehr?

EDIT: Wenn möglich wäre eine Reparatur des Profils natürlich eine noch bessere Lösung!

Danke und Gruss, Cedy

Hallo Leute,

wir haben momentan einen Schannel-Fehler im Ereignislog, der unser Log explodieren lässt, da er mehrfach in der Sekunde auftritt.

Server:

Windows Server 2008 R2 (Updates aktuell)

Exchange 2010 installiert (Updates aktuell)

Protokollname: System
Quelle:        Schannel
Datum:         12.07.2019 09:26:20
Ereignis-ID:   36887
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:
Benutzer:      SYSTEM
Computer:      ##########
Beschreibung:
Es wurde eine schwerwiegende Warnung empfangen: 46.
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"><System><Provider Name="Schannel" Guid="{1F678132-5938-4686-9FDC-C8FF68F15C85}" /><EventID>36887</EventID><Version>0</Version><Level>2</Level><Task>0</Task><Opcode>0</Opcode><Keywords>0x8000000000000000</Keywords><TimeCreated SystemTime="2019-07-12T07:26:20.886265300Z" /><EventRecordID>20630590</EventRecordID><Correlation /><Execution ProcessID="704" ThreadID="4524" /><Channel>System</Channel><Computer>##########</Computer><Security UserID="S-1-5-18" /></System><EventData><Data Name="AlertDesc">46</Data></EventData></Event>

Der Prozess ist lsass.exe und hier habe ich gleich einen Auszug aus dem procmon:

08:20:14,2880004	lsass.exe	704	RegQueryValue	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\8F43288AD272F3103B6FB1428485EA3014C0BCFE\Blob	BUFFER OVERFLOW	Length: 144
08:20:14,2880111	lsass.exe	704	RegQueryValue	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\8F43288AD272F3103B6FB1428485EA3014C0BCFE\Blob	BUFFER OVERFLOW	Length: 144
08:20:14,2880209	lsass.exe	704	RegQueryValue	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\8F43288AD272F3103B6FB1428485EA3014C0BCFE\Blob	SUCCESS	Type: REG_BINARY, Length: 1.833, Data: 59 00 00 00 01 00 00 00 16 00 00 00 52 00 53 00
08:20:14,2880345	lsass.exe	704	RegCloseKey	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\8F43288AD272F3103B6FB1428485EA3014C0BCFE	SUCCESS	
08:20:14,2880535	lsass.exe	704	RegEnumKey	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates	SUCCESS	Index: 13, Name: 9617094A1CFB59AE7C1F7DFDB6739E4E7C40508F
08:20:14,2880656	lsass.exe	704	RegQueryKey	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates	SUCCESS	Query: HandleTags, HandleTags: 0x0
08:20:14,2880914	lsass.exe	704	RegOpenKey	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\9617094A1CFB59AE7C1F7DFDB6739E4E7C40508F	SUCCESS	Desired Access: Read
08:20:14,2881144	lsass.exe	704	RegQueryValue	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\9617094A1CFB59AE7C1F7DFDB6739E4E7C40508F\Blob	BUFFER OVERFLOW	Length: 144
08:20:14,2881373	lsass.exe	704	RegQueryValue	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\9617094A1CFB59AE7C1F7DFDB6739E4E7C40508F\Blob	BUFFER OVERFLOW	Length: 144
08:20:14,2881486	lsass.exe	704	RegQueryValue	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\9617094A1CFB59AE7C1F7DFDB6739E4E7C40508F\Blob	SUCCESS	Type: REG_BINARY, Length: 1.286, Data: 19 00 00 00 01 00 00 00 10 00 00 00 54 78 18 7B
08:20:14,2881741	lsass.exe	704	RegCloseKey	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\9617094A1CFB59AE7C1F7DFDB6739E4E7C40508F	SUCCESS	
08:20:14,2882050	lsass.exe	704	RegEnumKey	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates	SUCCESS	Index: 14, Name: 98ED99A67886D020C564923B7DF25E9AC019DF26
08:20:14,2882189	lsass.exe	704	RegQueryKey	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates	SUCCESS	Query: HandleTags, HandleTags: 0x0
08:20:14,2882309	lsass.exe	704	RegOpenKey	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\98ED99A67886D020C564923B7DF25E9AC019DF26	SUCCESS	Desired Access: Read
08:20:14,2882451	lsass.exe	704	RegQueryValue	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\98ED99A67886D020C564923B7DF25E9AC019DF26\Blob	BUFFER OVERFLOW	Length: 144
08:20:14,2882584	lsass.exe	704	RegQueryValue	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\98ED99A67886D020C564923B7DF25E9AC019DF26\Blob	BUFFER OVERFLOW	Length: 144
08:20:14,2882685	lsass.exe	704	RegQueryValue	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\98ED99A67886D020C564923B7DF25E9AC019DF26\Blob	SUCCESS	Type: REG_BINARY, Length: 1.401, Data: 19 00 00 00 01 00 00 00 10 00 00 00 21 23 A9 CE
08:20:14,2882804	lsass.exe	704	RegCloseKey	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\98ED99A67886D020C564923B7DF25E9AC019DF26	SUCCESS	
08:20:14,2883009	lsass.exe	704	RegEnumKey	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates	SUCCESS	Index: 15, Name: A1DC024FC8B2A76745D4661F663B8741C3D35313
08:20:14,2883120	lsass.exe	704	RegQueryKey	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates	SUCCESS	Query: HandleTags, HandleTags: 0x0
08:20:14,2883264	lsass.exe	704	RegOpenKey	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\A1DC024FC8B2A76745D4661F663B8741C3D35313	SUCCESS	Desired Access: Read
08:20:14,2883390	lsass.exe	704	RegQueryValue	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\A1DC024FC8B2A76745D4661F663B8741C3D35313\Blob	BUFFER OVERFLOW	Length: 144
08:20:14,2883520	lsass.exe	704	RegQueryValue	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\A1DC024FC8B2A76745D4661F663B8741C3D35313\Blob	BUFFER OVERFLOW	Length: 144
08:20:14,2883622	lsass.exe	704	RegQueryValue	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\A1DC024FC8B2A76745D4661F663B8741C3D35313\Blob	SUCCESS	Type: REG_BINARY, Length: 1.321, Data: 19 00 00 00 01 00 00 00 10 00 00 00 FC E8 9E 67
08:20:14,2883762	lsass.exe	704	RegCloseKey	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\A1DC024FC8B2A76745D4661F663B8741C3D35313	SUCCESS	
08:20:14,2883942	lsass.exe	704	RegEnumKey	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates	SUCCESS	Index: 16, Name: A43489159A520F0D93D032CCAF37E7FE20A8B419
08:20:14,2884054	lsass.exe	704	RegQueryKey	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates	SUCCESS	Query: HandleTags, HandleTags: 0x0
08:20:14,2884173	lsass.exe	704	RegOpenKey	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\A43489159A520F0D93D032CCAF37E7FE20A8B419	SUCCESS	Desired Access: Read
08:20:14,2884325	lsass.exe	704	RegQueryValue	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\A43489159A520F0D93D032CCAF37E7FE20A8B419\Blob	BUFFER OVERFLOW	Length: 144
08:20:14,2884453	lsass.exe	704	RegQueryValue	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\A43489159A520F0D93D032CCAF37E7FE20A8B419\Blob	BUFFER OVERFLOW	Length: 144
08:20:14,2884578	lsass.exe	704	RegQueryValue	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\A43489159A520F0D93D032CCAF37E7FE20A8B419\Blob	SUCCESS	Type: REG_BINARY, Length: 1.312, Data: 59 00 00 00 01 00 00 00 10 00 00 00 52 00 53 00
08:20:14,2884806	lsass.exe	704	RegCloseKey	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\A43489159A520F0D93D032CCAF37E7FE20A8B419	SUCCESS	
08:20:14,2885102	lsass.exe	704	RegEnumKey	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates	SUCCESS	Index: 17, Name: BE36A4562FB2EE05DBB3D32323ADF445084ED656
08:20:14,2885229	lsass.exe	704	RegQueryKey	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates	SUCCESS	Query: HandleTags, HandleTags: 0x0
08:20:14,2885361	lsass.exe	704	RegOpenKey	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\BE36A4562FB2EE05DBB3D32323ADF445084ED656	SUCCESS	Desired Access: Read
08:20:14,2885481	lsass.exe	704	RegQueryValue	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\BE36A4562FB2EE05DBB3D32323ADF445084ED656\Blob	BUFFER OVERFLOW	Length: 144
08:20:14,2885605	lsass.exe	704	RegQueryValue	HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\BE36A4562FB2EE05DBB3D32323ADF445084ED656\Blob	BUFFER OVERFLOW	Length: 144

Ich vermute, dass dieser Buffer Overflow den Fehler verursacht, bin mir aber auch nicht sicher.

Die Hardwareauslastung ist nicht höher als sonst. 

Ich freue mich auf eure Tipps.

Grüße Turbomaik

Hallo Zusammne,

ich habe folgende Ausgangssituation:

Einen DHCP-Server, einen RADIUS-Server, einen Server mit ADDS und WDS. Als Switche sind Hp 5406.

Die Switche laufen alle auf aktueller Firmware.

In dem Netzwerk soll ich nun PXE Boot aktivieren, solange RADIUS nicht aktiviert wird.

Sobald auf den Port Radius aktiviert wird, kann ich keinen Boot mehr über PXE erstellen, ich erhalte einen Timeout beim Starten der PCs.

Gibt es eine Möglichkeit das die Clients den WDS erreichen können vor der RADIUS Authentifizierung oder ist das im Zusammenhang mit RADIUS nicht möglich.

Hallo zusammen!

Ich habe gerade meinen ersten 2016er installiert.

Leider musste ich feststellen, dass bei den Einstellungen für die Windows Updates nur eine Nutzungszeit bis zu 12 Stunden eingestellt werden kann. Was bei Clients extrem lästig, bei Servern aber total unsinnig ist.

Manchmal frage ich mich, in welcher Welt Entscheidungsträger leben und ob es nicht sinnvoll wäre, solche zu suchen, bei denen der ganz normale Hausverstand noch nicht verloren gegangen ist.

Leider habe ich auch noch keine GPO gefunden, die wirklich funktioniert. Ich bin trotzdem der Meinung, dass solch elementare Einstellungen auch so funktionieren müssten.

Gruß Franz

Hallo liebe Forenmitglieder, 

wir haben in unserer Umgebung folgendes Szenario: 
Jeder unserer AD-Benutzer ist Mitglied einer Gruppe, die nach seinem Anmeldenamen benannt ist. 
Beispiel User "Müller" ist Mitglied der Gruppe "Müller-G". User Müller ist auch das einzige Mitglied der Gruppe Müller-G. 
Unsere Verzeichnisrechte setzen wir also nicht mit dem User Müller, sondern immer der Gruppe Müller-G, in der der User selbst Mitglied ist. Diese Konstellation wurde vor etlichen Jahren in einer Schulung empfohlen, sodass wir dies bis heute beibehalten haben. 
Nun würden wir unsere Struktur mit der Gruppe Müller-G auflösen, sodass nur noch der User Müller vorhanden ist. 
Da ja all seine Berechtigungen unter der Gruppe Müller-G gesetzt wurden, können wir nicht einfach so die Gruppe entfernen, da der User selbst sonst keine Berechtigungen auf seine Verzeichnisse mehr besitzt. 

Nun die eigentlichen Fragen: 

- Ist es sinnvoll, diese o.g. Konstellation aus vorteilhaften Gründen trotzdem beizubehalten? 
In einem Artikel las ich, dass Benutzer selbst nicht auf das Verzeichnis direkt berechtigt werden sollten, da falls der User zu einem späteren Zeitpunkt gelöscht wird, im Berechtigungseintrag eine "verwaiste SID" zurückbleibt. 

- Gibt es eine Lösung, wie man alle gesetzten Verzeichnisrechte der Gruppe Müller-G auf den Benutzer Müller "übertragen" kann? Mittels kostenlosen Tools lassen sich ja Berechtigungen von Verzeichnissen einfach auslesen. Uns geht es um das Setzen der Berechtigungen, was bei etwa 400 AD-Benutzer alle manuell zu setzen sehr aufwendig wäre.  

- Wie verfahrt Ihr in eurer Umgebung? 

Natürlich verwenden wir auch allgemeine Gruppen, in denen mehrere User Mitglied sind. Wir haben aber auch Verzeichnisse, auf denen nur 1 User berechtigt ist, sodass wir in den Fällen nur mit Einzelrechten arbeiten können. 

Vielen Dank und mit freundlichen Grüßen, 

Anko93 

Hallo zusammen,

wir nutzen DFS-R zwischen Aussenstellen und Zentrale, um Daten auf einen zentralen Server zu replizieren und dort zu sichern.
Das Verfahren funktioniert offenbar grundsätzlich, aber wenn man sich ansieht, wieviel GB in den einzelnen Verzeichnissen liegen,
dann fällt auf, dass bei ca. 1100 GB im Verz. "DFS-Replikation" noch zusätzlich 439 GB unter "System Volume Information" gespeichert sind.

Nach meinem Kenntnisstand liegen dort Staging- und andere DFS-Verzeichnisse,
aber wieso bleibt die Verz.größe dort jetzt schon seit Wochen fast konstant bzw. wächst an?

Der Prozess müßte doch zwischengespeicherte (staging) Dateien irgendwann mal abbauen?

Kann es sein, dass DFS-R zur Replikation eines 500 GB Verzeichnisses auf dem Quell- und Zielserver "zusätzlich" jeweils 500 GB
freien Platz im Staging-Verzeichnis braucht?

Mit freundlichem Gruss,
Horst Wirth

Servus Community,

ein Windows 10 1903 EE Client zeigt nachdem er mit dem WSUS verbunden worden ist den Fehler 0x8024500c an. Als mögliche Ursache wird zB auf dieser Seite [1] der neu eingeführte Dual Scan erwähnt und ein möglicher Fix dafür veröffentlicht, der mich aber innehalten lässt.

Demnach soll folgende Richtlinie deaktiviert werden (die in unserer Richtlinie auch konfiguriert ist):

• Do not connect to any Windows Update Internet location

Dafür soll folgende Richtlinie aktiviert werden:

• Turn off access to all Windows Update features

Die Beschreibung dieser Richtlinie ist es jedoch, was mich nachfragen lässt. Sie klingt so als ob dadurch Windows Update vollständig deaktiviert wird:

---snip---

Wenn Sie diese Richtlinieneinstellung aktivieren, werden alle Windows Update-Funktionen entfernt. Dies umfasst auch die Blockierung des Zugangs zur Windows Update-Website unter "http://windowsupdate.microsoft.com" vom Hyperlink "Windows Update" im Startmenü und im Menü "Extras" des Internet Explorer. Die automatische Aktualisierung von Windows wird ebenfalls deaktiviert; Sie erhalten über Windows Update keine wichtigen Updates und werden auch nicht über neue Updates informiert. Durch diese Richtlinieneinstellung wird auch verhindert, dass der Geräte-Manager automatisch Treiberaktualisierungen von der Windows Update-Website installiert.

---snap---

Kann das tatsächlich richtig sein?

Und wenn Ja, kann ich diese Richtlinie auch auf ältere Windows 10 Builds als 1903 anwenden?

[1] http://blog.tofte-it.dk/wsus-windows-10-clients-error-0x8024500c/

Thx & Bye Tom

Hallo,

ich baue aktuell einen hierarchischen share für Kundenprojekte auf und versuche meinen Benutzern die Zugriffsrechte über Sicherheitsgruppen zu limitieren. Access based enumeration ist auf dem Fileserver (noch 2008 R2) eingeschaltet.

Die Struktur sieht so aus:

\\server\share (Share-Berechtigungen sind "full acces" für "Jeder")

Unterhalb des Shares ist jeweils ein Ordner pro Jahr, in dem jeweils Unterordner pro Kunde und darunter ein Ordner pro Projekt liegen.

Es existieren Gruppen pro Jahr (P2019-L , P2020-L, etc...) die folgende Reche auf das jeweilige Jahr haben:

Dadurch kann der Benutzer den Ordner sehen, aber darunterliegende Daten nur, wenn er dort auch entsprechende Rechte hat.

Die Kunden-Ordner haben dieselben Berechtigungseinträge, auf den Projektordner bekommt die entsprechende Gruppe Vollzugriff.

Das Problem ist das folgende:

Das ganze funktioniert nur, wenn ich anstelle der Gruppe *einmal* direkt den Benutzer mit diesen Rechten hier eingetragen habe - danach kann ich den wieder löschen und dann reicht es, wenn er in der entsprechenden Gruppe ist.

Woran könnte das liegen?

Hallo Zusammen

Momentan laufen noch etwa 10 ältere Windows Server 2008 R2 in unserer VMware Umgebung. Seit zwei Monaten ist uns aufgefallen, dass auf sechs von den zehn Servern der Prozess "TrustedInstaller.exe" einen grossen Teil der Ressourcen verbraucht. Dieser Prozess läuft 24/7. Die Performance-Einbussen sind stark spürbar. Daher haben wir versucht mal nachzuforschen was genau das Problem sein könnte.

Alle Updates sind installiert und es stehen keine weitere mehr an. Im WUClient Log finde ich immer wieder die gleichen Einträge:

Fehler bei der Suche nach Updates: 0x80072ee2.

Es wurde eine Änderung an der Integrität von Windows Update vorgenommen.

An Verbindungsproblemen kann es nicht liegen. Dem Server wurde per GPO einen WSUS als Update Server eingetragen. Ein Verbindungstest ist erfolgreich:

telnet server.domain 8530

Einen Blick ins Windows Update Log gibt mir folgende Zeilen:

_______________________________________________________________________________________________________

2019-08-05 14:48:35:874
992 a3c
Agent *************
2019-08-05 14:48:35:874
992 a3c
Agent ** START **  Agent: Finding updates [CallerId = <<PROCESS>>: cscript.exe]
2019-08-05 14:48:35:874
992 a3c
Agent *********
2019-08-05 14:48:35:874
992 a3c
Agent   * Online = Yes; Ignore download priority = No
2019-08-05 14:48:35:874
992 a3c
Agent   * Criteria = "IsInstalled = 0 and IsHidden = 0"
2019-08-05 14:48:35:874
992 a3c
Agent   * ServiceID = {00000000-0000-0000-0000-000000000000} Third party service
2019-08-05 14:48:35:874
992 a3c
Agent   * Search Scope = {Machine}
2019-08-05 14:48:35:890
992 a9c
Agent WARNING: WU client fails to call back to search call {1D389C4C-C76A-4530-AB96-D9A510668942} with error 0x800706ba
2019-08-05 14:48:36:186
992 a3c
PT +++++++++++  PT: Synchronizing server updates  +++++++++++
2019-08-05 14:48:36:186
992 a3c
PT   + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://wsus.domain.ch:8530/ClientWebService/client.asmx
2019-08-05 14:49:48:731
992 df8
AU Triggering AU detection through DetectNow API
2019-08-05 14:49:48:747
992 df8
AU Piggybacking on an AU detection already in progress
2019-08-05 14:49:48:809
2880 95c
Misc ===========  Logging initialized (build: 7.6.7601.24085, tz: +0200)  ===========
2019-08-05 14:49:48:809
2880 95c
Misc   = Process: C:\Windows\system32\cscript.exe
2019-08-05 14:49:48:809
2880 95c
Misc   = Module: C:\Windows\system32\wuapi.dll
2019-08-05 14:49:48:809
2880 95c
COMAPI -------------
2019-08-05 14:49:48:809
2880 95c
COMAPI -- START --  COMAPI: Search [ClientId = <NULL>]
2019-08-05 14:49:48:809
2880 95c
COMAPI ---------
2019-08-05 14:49:49:090
2880 95c
COMAPI <<-- SUBMITTED -- COMAPI: Search [ClientId = <NULL>]
2019-08-05 14:50:15:050
992 a3c
PT +++++++++++  PT: Synchronizing extended update info  +++++++++++
2019-08-05 14:50:15:050
992 a3c
PT   + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://wsus.domain:8530/ClientWebService/client.asmx
2019-08-05 14:50:15:939
992 a3c
Agent   * Added update {8275FFA7-5730-4D56-ABD2-504E6D07AB24}.200 to search result
2019-08-05 14:50:15:939
992 a3c
Agent   * Added update {3363F98B-78A3-44A7-93DF-D770B2DD150A}.206 to search result
2019-08-05 14:50:15:939
992 a3c
Agent   * Added update {01B22BD0-0DDF-4CD7-BBF3-5669E8C42DFF}.201 to search result
2019-08-05 14:50:15:939
992 a3c
Agent   * Added update {4F350CF0-B8FF-45B2-A827-B25C97690227}.202 to search result
2019-08-05 14:50:15:939
992 a3c
Agent   * Added update {1C930EAB-7B7E-4616-B5B5-D6E4A723BC71}.200 to search result
2019-08-05 14:50:15:939
992 a3c
Agent   * Added update {D5FA704A-BD09-4D9B-A68E-8DA1FE2642F7}.200 to search result
2019-08-05 14:50:15:939
992 a3c
Agent   * Found 6 updates and 80 categories in search; evaluated appl. rules of 1418 out of 2425 deployed entities
2019-08-05 14:50:15:955
992 a3c
Agent *********
2019-08-05 14:50:15:955
992 a3c
Agent **  END  **  Agent: Finding updates [CallerId = <<PROCESS>>: cscript.exe]
2019-08-05 14:50:15:955
992 a3c
Agent *************

_______________________________________________________________________________________________________

Neustarten der Server bringt nichts. Der Prozess startet sich immer wieder.

Hat da Jemand ähnliche Erfahrungen damit gemacht? 

Besten Dank!

Die Datei Package_for_RollupFix~31bf3856ad364e35~amd64~~7601.24405.1.12.mum fehlt.

Aber wo bekommt man die her?

Hier Log:

=================================
Checking System Update Readiness.
Binary Version 6.1.7601.22471
Package Version 26.0
2019-08-22 12:26

Checking Windows Servicing Packages

Checking Package Manifests and Catalogs

Checking Package Watchlist

Checking Component Watchlist

Checking Packages
(f)    CBS MUM Missing    0x00000002    servicing\Packages\Package_for_RollupFix~31bf3856ad364e35~amd64~~7601.24405.1.12.mum        

Checking Component Store

Summary:
Seconds executed: 535
 Found 1 errors
  CBS MUM Missing Total count: 1

Unavailable repair files:
    servicing\packages\Package_for_RollupFix~31bf3856ad364e35~amd64~~7601.24405.1.12.mum
    servicing\packages\Package_for_RollupFix~31bf3856ad364e35~amd64~~7601.24405.1.12.cat

(w)    Unable to get system disk properties    0x0000045D    IOCTL_STORAGE_QUERY_PROPERTY    Disk Cache   

Hallo

Heute hatte ich eine äusserst skurrile Situation mit einem 2008 R2 Kundenserver den wir nicht selber eingerichtet haben, sondern erst vor kurzem "geerbt" im Hinblick auf einen baldigen Ersatz durch neuen Server & aktuelles Server-OS. (Die Firma/Person welche den Server seinerzeit eingerichtet hat ist nicht mehr greifbar.)

Der Hilferuf des Kunden ereilte mich am mittleren Nachmittag und lautete so:

"Bis heute Mittag lief in unserer ERP-Software alles normal. Als ich nach dem Mittagessen weiterarbeiten wollte habe ich festgestellt, dass sämtliche Daten der letzten zwei Monate aus dem ERP verschwunden sind. Der Anbieter der ERP-Software hat eine Fernwartung gemacht und kann sich dies auch nicht erklären. Er hat nach einem BackUp gefragt, deswegen rufen wir jetzt an."

Also mache ich ebenfalls eine Fernwartung auf den Server und stelle fest:

Die ganze Kiste befindet sich auf dem Stand von Anfang Juni!

Nicht nur die ERP-Software. Alles. Beispielsweise das Verzeichnis in dem ein tägliches BackUp der Datenbank geschrieben wird bevor wir es von dort wegbackuppen.

Oder auch die Windows-Ereignisanzeige: Dort klaffte eine 2,5-Monatige Lücke zwischen dem Abend des 5.6. und heute Mittag, 12:50.

Kurzum: Es sieht danach aus, wie wenn die Kiste heute Mittag zwischen 12 und 13 Uhr aus unerfindlichen Gründen eine komplette Systemwiederherstellung auf den Stand vom 5.6. gemacht hätte...

Nur stellt sich mir hier die Frage, wie das überhaupt möglich gewesen sein soll. Zwar hängt an der Kiste tatsächlich noch eine externe HDD auf welche tägliche Vollsicherungen (mit der Windows Server Sicherung) gemacht werden, doch könnte man die m.E. aus der Ferne (mit WSS) gar nicht in einer solchen Vollständigkeit wiederherstellen, oder irre ich mich da?

Einzig "plausible" Erklärung wäre daher auf den ersten Blick dass da zwischen 12 und 13 Uhr einer in den Serverraum marschiert ist, Windows RE gebooted hat und eine Recovery auf ein Abbild vom 5.6. durchgeführt hat... nur dass das eben auch nicht wirklich plausibel ist. (Zwar theoretisch denkbar, aber doch irgendwie sehr unwahrscheinlich...)

Entweder bin ich total überarbeitet und blicke gar nicht mehr durch (wär nach dem pausenlosen Hochbetrieb dieses Jahr durchaus denkbar) oder das Ganze ist doch sehr mysteriös, oder?

Bin gespannt auf eure Theorien.

moin,

wir haben (historisch gewachsen) auf einem AD Controller das Volume Activation Service laufen. Der DC "xyz" 2012, wird jetzt durch einen neuen 2016 mit gleichem Namen ersetzt.

Ich nehme an die Volume Keys liegen nicht im AD? Wie können wir daher irgendwie die gesamte VL DB sichern und importieren? bzw. übernehmen?

Chris

Ich habe einen alten Server 2008  es läuft ein VM  mit 30gb.

Ich möchte 2 VM mit noch mal 30gb einrichten,aber die 2 VM nehmt immer nur 1000mb was mache ich verkehrt?

Danke in Voraus 

Hallo,

ich möchte zwischen einem Server 2008 R2 und einem Server 2012 R2 eine DFS Replikation einrichten. Allerdings schlägt die Initialreplikation immer mit folgender Fehlermeldung fehl:

Der DFS-Replikationsdienst hat die Replikation für den replizierten Ordner unter dem lokalen Pfad "C:\Ordner" beendet.
 
Weitere Informationen:
Fehler: 9003 (Die Replikationsgruppe ist ungültig.)
Weiterer Kontext des Fehlers:   
Name des replizierten Ordners: Ordner
ID des replizierten Ordners:
Replikationsgruppenname: Daten
Replikationsgruppen-ID:
Mitglieds-ID:

Kann mir jemand sagen, was diesen Fehler auslöst und wie ich die Replikation zum laufen bekomme?