Windows-Prozessaktivierungsdienst startet nicht – Fehler 6801

Auf einem Windows-Server (in dem Fall ein 2008 R2) mit IIS starteten die IIS-Dienste nicht, da der Windows-Prozessaktivierungsdienst mit folgender Fehlermeldung nicht starten wollte:

„Windows konnte den Prozessaktivierungsdienst nicht sarten – Fehler 6801: Die Transaktionsunterstützung im angegebenen Ressourcen-Manager wurde nicht gestartet oder aufgrund eines Fehlers heruntergefahren“

bzw.:

„Windows could not start the Windows Process Activation Service – Error 6801: Transaction support within the specified resource manager is not started or was shut down due to an error“

Das Problem kann man folgend lösen:

eine Eingabeaufforderung (cmd) als Administrator startet und folgenden Befehl ausführen:

fsutil resource setautoreset true c:\

Danach muss man den Server neu starten – jetzt sollte der WAS (Windows-Prozessaktivierungsdienst) wieder starten – und somit auch die davon abhängigen IIS-Dienste 🙂

Quelle: forum.iis.net

Powershell: Programm oder Skript mit Credentials und „als Administrator“ ausführen

Manchmal muss man unter Windows ein Programm oder ein Skript mit speziellen Credentials ausführen und zusätzlich „als Administrator“ ausführen.

Das funktioniert über die Powershell einfach wie folgt:

$User = "Username"
$Password = "Password" | ConvertTo-SecureString -asPlainText -Force
$MyCredential = New-Object System.Management.Automation.PSCredential($User,$Password)

Start-Process -WindowStyle Hidden powershell.exe -Credential $MyCredential -ArgumentList '-noprofile -command &{Start c:\program\program.exe -Verb RunAs}'

Hier wird eine Powershell.exe mit den angegebenen Username und Passwort ausgeführt (Klartext-Passwörter sind natürlich schlecht – dienen hier nur als Beispiel!) und der Powershell.exe wird das Programm zum ausführen übergeben mit dem Attribut -Verb RunAs dass das Programm „als Administrator“ ausführt.

fertig 🙂

Windows 10 kann auf NetApp Cifs Freigaben nicht zugreifen

Ich hatte das Problem dass ein neuer Rechner mit Windows 10 nicht auf Cifs-Freigaben auf einem NetApp-Filer zugreifen konnte. Der alte Trick mit dem Ausschalten des „Sicheren Aushandeln“ – der Secure Negotiaten – funktionierte nicht mehr…

Lösung:

Auf der NetApp (per SSH) folgenden Befehl ausführen:

options cifs.smb2.signing.required on

Danach funktionierte der Zugriff reibungslos 🙂

Microsoft: KB3159398 macht Probleme bei der Gruppenrichtlinenverarbeitung

Das KB3159398, dass über Windows Update zur Zeit verteilt wird, ändert ein wenig die Art und Weise wie die Sicherheitsfilterung bei der Gruppenrichtlinienverarbeitung funktioniert.

Das kann zu Problemen führen, wie z.B.:

– Laufwerke werden nicht mehr gemappt
– Desktop-Symbole für Verknüpfungen werden nicht mehr sauber angezeigt
– Diverse Gruppenrichtlinien (z.B. Druckerzuweisungen, etc) funktionieren nicht mehr

Das Problem liegt an einem fehlendem Lese-Recht des Authentifizierte Benutzer (Authenticated Users) unter Delegierung, dass durch den Patch jetzt allerdings benötigt wird.

In dem KB dazu hat Microsoft das Problem auch beschrieben:

Known issues

MS16-072 changes the security context with which user group policies are retrieved. This by-design behavior change protects customers’ computers from a security vulnerability. Before MS16-072 is installed, user group policies were retrieved by using the user’s security context. After MS16-072 is installed, user group policies are retrieved by using the machines security context. This issue is applicable for the following KB articles:

3159398 MS16-072: Description of the security update for Group Policy: June 14, 2016
3163017 Cumulative update for Windows 10: June 14, 2016
3163018 Cumulative update for Windows 10 Version 1511 and Windows Server 2016 Technical Preview 4: June 14, 2016
3163016 Cumulative Update for Windows Server 2016 Technical Preview 5: June 14 2016

Symptoms

All user Group Policy, including those that have been security filtered on user accounts or security groups, or both, may fail to apply on domain joined computers.

Cause

This issue may occur if the Group Policy Object is missing the Read permissions for the Authenticated Users group or if you are using security filtering and are missing Read permissions for the domain computers group.

Resolution

To resolve this issue, use the Group Policy Management Console (GPMC.MSC) and follow one of the following steps:
– Add the Authenticated Users group with Read Permissions on the Group Policy Object (GPO).
– If you are using security filtering, add the Domain Computers group with read permission.

Lösung: Die Authentifizierten Benutzer manuell mit dem Lese-Recht bei den Delegierungen hinzufügen

AuthUsersGPO

Es gibt auch hier ein Script dass das automatisch macht.

Empfehlenswerter Artikel zu lesen: http://www.gruppenrichtlinien.de/artikel/sicherheitsfilterung-neu-erfunden-ms16-072-patchday-14062016/

Windows: Event 2103 – AD-Datenbank wurde anhand eines Verfahrens nicht unterstützte Wiederherstellung wiederhergestellt

Ich hatte in einem AD das Problem, dass nach einem Restore aus einem Snapshot die Domain Controllern die Anmeldung der User verweigerten und auch untereinander nicht mehr replizierten. Im Eventlog wurde folgender Fehler protokolliert:

Ereignistyp: Fehler
Ereignis Quelle: NTDS Allgemein
Ereigniskategorie: Steuerung
Ereignis-ID: 2103
Beschreibung: Die Active Directory-Datenbank wurde anhand eines Verfahrens nicht unterstützte Wiederherstellung wiederhergestellt. Active Directory können Benutzer anmelden, während das Problem weiterhin besteht. Als Ergebnis wurde der Netlogon-Dienst angehalten. Benutzer Aktion Siehe vorherige Ereignisprotokolle Einzelheiten. Weitere Informationen finden Sie im Hilfe- und Supportcenter unter http://support.microsoft.com.

Und bei der Replikation wurde die Fehlermeldung (z.B. bei repadmin /showrepl)

Der Quellserver nimmt keine Replikationsanforderung entgegen

ausgegeben.

Das ganze Problem wurde verursacht, dass durch die nicht unterstützte Wiederherstellung – in meinem Fall ein Snapshot – die Datenbank der Active Directorys auf Not Writeable gesetzt wurde.

Das ganze wieder ans laufen bekommt man wenn man in der Registry auf dem DC unter

HKLM\System\CurrentControlSet\Services\NTDS\Parameters

den Wert „Dsa Not Writable“ von 4 auf 0 setzt.

Dazu legt man noch einen REG_DWORD “Ignore USN Rollback” an und setzt den Wert auf 0

Danach muss man den Server neustarten.

Damit die Replikation wieder sauber funktioniert muss man auf allen DC-Servern die Befehle

repadmin /options “ServerName” -DISABLE_OUTBOUND_REPL
repadmin /options “ServerName” -DISABLE_INBOUND_REPL

ausführen – wobei „ServerName“ mit dem jeweiligen lokalen Servernamen des DCs ersetzten.

Jetzt sollte eigentlich alles laufen.

Falls allerdings die Replikation noch nicht funktioniert – oder andere Fehler im Eventlog protokolliert werden – kann noch ein Reset des Passwortes des Computerkontos der Domaincontroller nötig sein.

Das macht man auf den DCs folgendermaßen (am besten davor einen Reboot machen):

netdom resetpwd /server:anderer_dc /userd:domain\administrator /passwordd:*

Danach den Server rebooten.

Jetzt sollte es wirklich wieder laufen 🙂

Quelle: hyper-v-server.de

ActiveDirectory Rechte-Vererbung mittels Powershell einschalten

Die Rechte-Vererbung im ActiveDirectory ist manchmal bei bestimmten Benutzern deaktiviert – selten ist das gewollt – fast immer gibt es aber deswegen (vor allem in Verbindung mit Exchange) Probleme.

Einige Beispiele:

– ExchangeSynchronisationsfehler 86000C0A bei betroffenen Benutzern, obwohl OWA korrekt funktioniert

– Dateisystems-Auflistung im Explorer schlängt mit 0x86000Cxx Fehlern fehl

Fehler im Ereignisprotokoll von MSExchange ActiveSync mit dem Inhalt „Active directory Antwort: 00000005: SecErr: DSID-031521D0, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0″.“

Exchange: das Verschieben der Mailbox der Benutzer (z.B. bei Exchange-Migrationen) schlägt fehl

Bei einem Benutzer kann man die Vererbung wie hier beschrieben ja manuell aktivieren – bei vielen Usern ist da ein automatisierter Weg zu empfehlen….

Das kann man ganz einfach mit der Powershell erledigen! Einfach die PowerShell ISE als Administrator ausführen und folgendes Script ausführen:

Import-Module activedirectory
$OU = "OU=INDIESEROUWERDENUSERGESUCHT,DC=MEINDOMAENE,DC=TLD"
$Users=get-aduser -Filter * -SearchBase $OU

if ($Users -ne $null) 
{

    foreach ($Entry in $Users) 
    {
    [string]$dn = (Get-ADUser $Entry).DistinguishedName
    $user = [ADSI]”LDAP://$dn”
    $acl = $user.objectSecurity
    Write-Host "Pruefe Benutzer:" (Get-ADUser $Entry).SamAccountName

        if ($acl.AreAccessRulesProtected)
        {
        Write-Host "Fixe Benutzer:" (Get-ADUser $Entry).SamAccountName
        $acl.SetAccessRuleProtection($false,$true)
        $inherited = $acl.AreAccessRulesProtected
        $user.commitchanges()
        }
    }

}

else 
{
    Write-Host "Keine Benutzer in $OU gefunden"
}

In der Zeile $OU = „OU=INDIESEROUWERDENUSERGESUCHT,DC=MEINDOMAENE,DC=TLD“ einfach die ensprechende OU angeben und alle Benutzer – auch in Unter-OUs – werden angepasst 🙂

Quelle: ugg.li

Änderungen in Log-Dateien unter Windows beobachten

Unter Linux/Unix/BSD verwende ich ja immer tail um Änderungen in Log-Dateien live zu verfolgen.

Unter Windows kann man das mit der Powershell tun:

Get-Content logfile.log –Wait

TailWindowsPowershell1

Man kann aber auch nach einen String darin filtern

Get-Content logfile.log –Wait | where { $_ -match “Success” }

TailWindowsPowershell2

Zwar nicht so mächtig wie tail – aber auch nicht schlecht 😉

Gruppenrichtlinienverwaltung: Fehler bei der Anzeige

Ich hatte das Problem auf einem Windows Server 2008 R2, dass die Gruppenrichtlinienverwaltung bei der Anzeige oder Bearbeitung folgenden bzw. ähnliche Fehler anzeigte:

Die in der Eigenschaft „$(string.VerMgmtAuditModeEnable)“ aufgeführte Ressource displayName konnte nicht gefunden werden.

Datei C:\Windows\PolicyDefinitions\inetres.admx, Zeile 1495, Spalte 249

Um wieder mit der GPMC arbeiten zu können muss man folgendes tun:

1) Download der Administrative Templates for Internet Explorer bei Microsoft

2) Ersetzen folgender drei Dateien durch die aus dem heruntergeladenen ZIP-Datei:
C:\Windows\PolicyDefinitions\InetRes.admx
C:\Windows\PolicyDefinitions\en-US\InetRes.adml
C:\Windows\PolicyDefinitions\de.DE\InetRes.adml

Normalerweise muss man davor den Besitzer der Dateien von trustedInstaller auf den aktuellen Admin-Benutzer ändern – da man sonst die Dateien nicht ersetzten kann.

Danach die Gruppenrichtlinienverwaltung wieder öffnen und schon gehts 🙂

Quelle: Administrator.de

Nach Druckservermigration Drucker am Client umziehen

Nachdem man – hoffentlich – erfolgreich einen Druckserver von einem Windows-Server auf einen anderen umgezogen hat ist der nächste Schritt die Umstellung auf den Clients. Wenn ich nicht Gruppenrichtlinien zur Druckerzuordnung verwenden kann verwende ich ein VB-Sript um die Drucker des Benutzers umzuziehen. Wenn der Benutzer das Script ausführt – entweder über eine Gruppenrichtlinie verteilt oder per login-script – werden die alten Drucker gelöscht und die Drucker automatisch über den neuen Druckserver verbunden – inklusive das setzten des Standarddruckers.

Bitte beachten: Die Freigabenamen der Drucker auf dem alten und auf dem neuen Druckserver müssen gleich sein. Falls es die für den alten Drucker verwendete Freigabe auf dem neuen Druckserver nicht gibt wird der Drucker gelöscht.

Hier das Script – die Variablen from_sv und to_sv anpassen und als .vbs abspeichern

Option Explicit
Dim from_sv, to_sv, PrinterPath, PrinterName, DefaultPrinterName, DefaultPrinter
Dim DefaultPrinterServer, SetDefault, key
Dim spoint, Loop_Counter, scomma
Dim WshNet, WshShell
Dim WS_Printers
DefaultPrinterName = ""
spoint = 0
scomma = 0
SetDefault = 0
set WshShell = CreateObject("WScript.shell")

from_sv = "\\sv-alt" 'Der alte Druckserver.
to_sv = "\\sv-neu" 'Der neue Druckserver.

On Error Resume Next
key = "HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\Device"
DefaultPrinter = LCase(WshShell.RegRead (key))

If Err.Number <> 0 Then
	DefaultPrinterName = ""
else
spoint = instr(3,DefaultPrinter,"\")+1

DefaultPrinterServer = left(DefaultPrinter,spoint-2)

	if lcase(DefaultPrinterServer) = from_sv then
		DefaultPrinterName = mid(DefaultPrinter,spoint,len(DefaultPrinter)-spoint+1)
		scomma = instr(DefaultPrinterName,",")
		DefaultPrinterName = left(DefaultPrinterName,scomma -1)
	end if
end if

Set WshNet = CreateObject("WScript.Network")
Set WS_Printers = WshNet.EnumPrinterConnections

For Loop_Counter = 0 To WS_Printers.Count - 1 Step 2
	PrinterPath = lcase(WS_Printers(Loop_Counter + 1))

	if lcase(LEFT(PrinterPath,len(from_sv))) = from_sv then
		spoint = instr(3,PrinterPath,"\")+1
		PrinterName = mid(PrinterPath,spoint,len(PrinterPath)-spoint+1)
		WshNet.RemovePrinterConnection from_sv+"\"+PrinterName
		if lcase(PrinterName) <> "c6100" then
			WshNet.AddWindowsPrinterConnection to_sv+"\"+PrinterName
			if DefaultPrinterName = PrinterName then
				WshNet.SetDefaultPrinter to_sv+"\"+PrinterName
			end if
		end if
	end if
Next
Set WS_Printers = Nothing
Set WshNet = Nothing
Set WshShell = Nothing

' wscript.echo "Drucker migriert"

Wenn man das Script z.B. in einem Logon-Script beim Anmelden des Benutzers ausführen lässt, muss man in der Login-BAT bzw. CMD die Zeile

cscript //nologo drucker-migrieren.vbs

einfügen.

Dann werden beim anmelden alle Drucker automatisch umgezogen.

Funktionierte bei mir schon bei einigen Migrationen wunderbar 🙂

Quelle: https://gallery.technet.microsoft.com/

Active Directory: Servernamen in Profilpfad und Basisordner ändern

Wenn man bei vielen Benutzern in einem Active Directory den Server im Profilpfad oder im Basisordner (Home, Home Folder) ändern muss – und nicht alle User einzeln über die GUI ändern will – kann man das am besten über die PowerShell machen.

So kann man bei allen Benutzer in einem Rutsch den Servernamen im UNC-Pfad des Profiles ändern:

Import-Module ActiveDirectory

$oldServerName = "sv-alt"
$newServerName = "sv-neu"

[array]$AllUsers = Get-ADUser -filter * -Properties profilepath | Where-Object {$_.profilepath -ne $null}

foreach($user in $AllUsers){

if(($user.profilepath.ToString()).contains($oldServerName)){
$profilepath = ($user.profilepath.ToString()) -replace $oldServerName, $newServerName
Set-ADUser $user.DistinguishedName -profilepath $profilepath
}

}

und so kann man bei allen Benutzern den Server im UNC-Pfad des Basisordners ändern:

Import-Module ActiveDirectory

$oldServerName = "sv-alt"
$newServerName = "sv-neu"

[array]$AllUsers = Get-ADUser -filter * -Properties HomeDirectory | Where-Object {$_.homedirectory -ne $null}

foreach($user in $AllUsers){

if(($user.HomeDirectory.ToString()).contains($oldServerName)){
$homeDirectory = ($user.HomeDirectory.ToString()) -replace $oldServerName, $newServerName
Set-ADUser $user.DistinguishedName -HomeDirectory $homeDirectory
}

}

Einfach die Servernamen anpassen und am besten in ein Powershell-Script (z.b home.ps1 und/oder profile.ps1) speichern und am Domänencontroller ausführen.

Ich überprüfe immer mit dem Befehl vorher und danach ob alles geklappt hat 🙂

HomePath-ProfilePath-BulkChange

So kann man wunderbar und superschnell eine schöne Bulk-Migration der Home Folder bzw. Profile machen 🙂

Die Scripte können hier runtergeladen werden: HomePath-ProfilePath-Bulk.zip

Quelle: https://community.spiceworks.com