Wenn man auf einem Windows Server das Dedup-Feature einschaltet kann es passieren, dass der ChunkStore (dieser befindet sich in dem Ordner „System Volume Information“) in dem die Informationen für das Dedup gespeichert werden immer weiter wächst und so riesig wird das er teilweise den ganzen freien Platz auf dem Volume verbraucht.

Das kann man aber über einen DedupJob aber wieder fixen -hier am Beispiel eines Volumes F: :

eine Powershell als Administrator öffnen

und

Start-DedupJob -Volume “F:” -Type GarbageCollection -Memory 50

man kann mit

Get-DedupJob

überprüfen wie weit der Job schon ist.

Hilft dies nicht ist eine Möglichkeit noch die Deduplizierung rückgänging zu machen.

Dazu lässt man Dedup auf dem Volume aktiviert – deaktiviert aber die Hintergrundaktivität

Set-DedupSchedule BackgroundOptimization -enable $false

Start-DedupJob -Volume „F:“ -Type Unoptimization

Start-DedupJob -Volume “F:” -Type GarbageCollection

danach sollte der Chunk-Ordner weg sein – dann kann dedup bei Bedarf wieder aktiviert werden.

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

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 🙂

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 🙂

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/

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

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

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

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 🙂

Hier ist das Script in einm ZIP zum Download: drucker-migrieren.zip

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