Hope This Helps

Problem : Man möchte den Besitz eines Ordners und dessen Unterordners übernehmen oder Berechtigungen setzen. In meinem Fall hatte sich ein Mitarbeiter aus seiner eigenen Backup Platte ausgesperrt.

Lösung :
Den Besitz übernehmen kann man mit dem kleinen Tool takeown.exe hier ein Beispiel für die externe HDD die bei mir als Z:\ gemountet wurde.

takeown.exe /F Z:\ /R /A /SKIPSL

Dieser Aufruf bewirkt das der Besitzer des Laufwerkes Z:\ auf die Gruppe Administratoren (/A) geändert wird. Der Parameter /SKIPSL bewirkt das keiner symbolischen Verknüpfung gefolgt wird. Das /R steht für rekursiv, d.h. alle Dateien und Unterordner bekommen den selben Besitzer. /F definiert eine Datei oder einen Ordner. Sollte der Parameter /A weggelassen werden wird der aktuell angemeldete Benutzer als Besitzer gesetzt.

Die Berechtigung kann man schön mit dem Tool icacls.exe ändern. Hier wieder das Beispiel mit der externen HDD die auf Z:\ gemountet ist.

icacls.exe Z:\* /grant Jeder:(OI)(CI)(F) /L

Dieser Aufruf schlüsselt sich so auf. icacls.exe ist das Programm Z:\* bedeutet das die Berechtigung auf das Laufwerk Z:\ und alles Dateien & Unterordner geändert wird. /grant setzt die Berechtigung. Jeder:(OI)(CI)(F) das ist die Gruppe Jeder mit den Einstellungen (OI)=Objektvererbung (CI)=Containervererbung (F)=Vollzugriff. Der Parameter /L bewirkt das die Berechtigung auf den symbolischen Link geändert wird nicht aber auf das Ziel des symbolischen Links.

ICACLS Parameter : https://technet.microsoft.com/de-de/library/cc753525(v=ws.10).aspx
TAKEOWN Parameter : https://technet.microsoft.com/de-de/library/cc753024(v=ws.10).aspx

Problem :
Windows Server 2008 R2 / Windows 8.1 / Windows Server 2012R2 startet auf einer ESXi 4.1 nicht richtig. Es kommt immer zu einem Bluescreen mit der Information CRITICAL_STRUCTURE_CORRUPTION

Lösung :

Ein Update für ihre ESXi Maschine kann dieses Problem beheben.
Da es sich in meinem Fall um einen ESXi 4.1 handelte hier der andere Weg.
Ein Workarround ist eine eigene CPUID Mask für die betroffene Maschine zu erstellen.

1.) ausschalten der betroffenen virtuellen Maschine
2.) Einstellungen der vm bearbeiten
3.) Auf das Register Optionen wechseln
4.) auf CPUID Mask klicken
5.) auf Erweitert klicken und eine CPUMASKID eintragen

Für Intel CPU den Wert unter Level 80000001.edx auf ----:0---:----:----:----:----:----:---- ändern
Für AMD Cpu den Wert unter Level 80000001.edx auf ----0--------------------------- ändern




Quelle :
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2060019

Problem : Man möchte einen Windows 2012 R2 Server auf einer VMWare ESXi 4.1 Infrastruktur installieren. Dies scheitert leider mit einem Bluescreen von Windows 2012 R2 Server. ESXi 4.1 unterstützt diese Plattform nicht, mit einem kleinen Eingriff kann man es aber überreden.

Lösung :

1.) Erstellen einer virtuellen Maschinen mit dem Gasttemplate Windows 2008 R2 (64Bit) Server
2.) Nach dem erstellen diese Datei herunterladen und im Pfad der Maschine auf der ESXi Kiste abspeichern.
3.) Direkt nach dem erstellen der Maschine muss die vmx Datei angepasst werden.
Diesen Eintrag hinzufügen :

bios440.filename = "bios.440.rom"
mce.enable = TRUE
cpuid.hypervisor.v0 = FALSE
vmGenCounter.enable = FALSE

4.)Anschalten der virtuellen Maschine und installieren

Kleiner Tipp um das ROM auf den ESXi zu übertragen ist das Tool WinSCP gut geeigent



Solltet ihr danach einen den Fehler bekommen CRITICAL_STRUCTURE_CORRUPTION lest euch das hier durch :
http://hope-this-helps.de/serendipity/archives/459-VmWare-ESXi-4.1-Windows-2012-R2-Server-CRITICAL_STRUCTURE_CORRUPTION.html

Quelle :
https://jgiffard.wordpress.com/
http://communities.vmware.com/servlet/JiveServlet/download/2139717-98102/bios.440.rom

Problem:
Der Windows Remote Management Dienst starte nicht mehr. Versucht man Ihn manuell zu starten, wird er sofort wieder beendet.
Ein Blick ins Ereignisprotokoll zeigt den Fehler 1300 für WinRM:


Lösung:
Nach kurzer Suche im Netz habe ich auch gleich eine Lösung gefunden. Damit der Dienst starten kann benötigt der Dienst-Benutzer das Recht zum "Generieren von Sicherheitsüberwachungen". Ich wollte dies mittels "secpol.msc" anpassen auf dem Server, aber da war das Hinzufügen ausgegraut. Nach kurzer Suche, war mir klar warum...es handelt sich hierbei um einen Domänencontroller und somit war die Änderung dieser Einstellung nur über die "Default Domain Controller Domain Controllers Policy" möglich. Hier habe ich folgendes angepasst:

- Navigieren zu "Richtlinie" -> "Windows-Einstellungen" -> "Sicherheitsrichtlinien" -> "Zuweisen von Benutzerrechten" -> "Generieren von Sicherheitsüberwachungen"

- Hier den zusätzlichen Benutzer eintragen (bei mir der Netzwerkdienst)

- Policy schließen und "gpupdate" auf dem DC ausführen

- WinRM-Dienst starten -> Fertig!

HINWEIS: Bei Member-Servern (Nicht-DCs), kann die Änderung auch über "Secpol.msc" durchgeführt werden.

Quelle zur Lösungsfindung:
XenDesktop 5.6 – The WinRM service is unable to start.

wir hatten ja letztes Jahr einen Outlook-Patch, der uns viel Kummer bereitet hat!
Damals haben wir uns manuell auf die Deinstallations-Runde gemacht, hätten das aber leichter haben können.
Ich bin heute wieder darüber gestolpert, als ich den WSUS für Stadelhofen vorbereitet habe.

Man kann ein Update anklicken und für eine Gruppe gezielt „Zur Entfernung genehmigen“.
Hier mal ein Beispiel:



So einfach hätte die Welt sein können! ?
…das nächste Mal wissen wir es und das nächste Mal kommt bestimmt…Danke Microsoft! ?

Problem:
Wenn man einen Benutzer anmelden möchte, dann erhält dieser nur ein „temporäres Profil“ und alle Einstellungen sind weg.

Lösung:
Irgendwie wurde das Profil beschädigt und wird nun nicht mehr von Windows geladen. Zur Lösung bitte folgende Schritte durchführen:
- Anmelden als Administrator an dem PC (darf nicht der betroffene Benutzer sein!!)
- Umbenennen des fehlerhaften Profile unter C:\Users\
- Neuanmeldung des Benutzers – Profil sollte wieder generiert werden

Wenn danach immer noch das temporäre Profil geladen wird, dann ist der Eintrag in der ProfileList in der Registry noch beschädigt.Das Problem kann wie folgt behoben werden:

- Als Admin Registry öffnen
- Navigieren zu: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

- Hier werden alle SIDs der Profile angezeigt, die auf dem Rechner angelegt wird
- Suchen Sie nach dem entsprechenden Profil, meistens zu erkennen mit der Endung „.bak“


- Exportieren Sie diesen Schlüssel zur Sicherheit
- Danach können Sie diesen Schlüssel löschen
- Melden Sie sich mit dem betroffenen Benutzer an – Verzeichnis und Profil-Pfad werden wieder generiert
- Kopieren Sie die Daten von dem zuvor umbenannten Profil wieder in das neu generierte Profil
- FERTIG!