Die Core Leute

Problem Step Recorder (PSR) - und Problem hierzu unter Windows 7

msft.cadumi — Tue, 12 Apr 2016 09:06:12 GMT

Hallo Zusammen, Das Problem Step Recorder Tool ist Teil von Windows und wurde ab Windows 7 hinzugefügt. Mittels des PSR-Tools (Problemaufzeichnungstool) ist es möglich, Schritt für Schritt die Vorgehensweise eines Benutzers bspw. bei der Reproduktion eines Problems, aufzuzeichnen. Hierbei wird bei jedem Klick des Benutzers ein Screenshot generiert. Die Ergebnisse werden in einer gezippten MHT-Datei gespeichert. Um das Problemaufzeichnungstool zu benutzen gehen Sie wie folgt vor: 1. Gehen Sie zur Start Seite und suchen Sie nach "Problem Steps Recorder" oder starten Sie den "Ausführen" Dialog (WIN+R) und geben PSR.EXE ein. 2. PSR kann als Standard User oder als Admin gestartet werden 3. Das Problem Step Recorder Fenster wird sich öffnen 4. Wenn Sie das Fenster als Admin geöffnet haben, wählen Sie den Link Einstellungen (Pfeil neben dem Fragezeichen) um die Einstellungen zu verändern. Zwar "Anzahl der kürzlich erstellten zu speichernden Bildschirmaufnahmen" kann von 25 auf 200 erhöht werden. Aufzeichnung der Schritte: 1. Wenn Sie bereit sind das Problem zu reproduzieren, klicken Sie auf die Schaltfläche den Start Record Knopf. 2. Gehen Sie durch alle Schritte um das Problem zu reproduzieren. Bei jedem Klick wird ein Screenshot erstellt. 3. Wenn das Problem komplett reproduziert wurde, beenden Sie die Aufzeichnung indem Sie Stop Record anklicken. 4. Im Anschluss wird das "Speichern unter" Dialogfenster angezeigt. Speichern Sie die Datei. Diese wird in einem gezippten Format ghespeichert. 5. Sobald die Datei gespeichert wurde, überprüfen Sie den Inhalt und stellen Sie sicher, dass die Aufnahme von der ersten bis zur letzten Aktion aufgezeichnet wurde. Hinweis: Nach der Einspielung der Security Updates MS15-085 (KB3082487 und/oder KB3071756) funktioniert der Problem Step Recorder unter Windows 7 nicht mehr wie erwartet. Bei der Aufzeichnung erhält man entweder die Fehlermeldung: PSR.exe an error occured while attempting to save the recorded steps oder die Aufzeichnung ist nicht vollständig / keine Bilder wurden aufgezeichnet Um die Probleme zu beheben, spielen Sie bitte das Update KB3121918 ein. https://support.microsoft.com/en-us/kb/3121918 - MS16-007: Description of the security update for Windows: January 12, 2016 Grüsse, Carmina

Forwarded Events - Inconsistent view / different from source *** Weitergeleitete Events sind inkonsistent

msft.cadumi — Mon, 11 Apr 2016 15:44:36 GMT

Hallo zusammen, hiermit möchte ich euch die Lösung zum folgenden Szenario präsentieren. Unter unterschiedlichen Serverversionen (2008R2, 2012, 2012R2) wurde bemerkt, dass manchmal die weitergeleiteten Ereignisse nicht wie gewünscht auf dem Event Collector Server ankommen. Dies ist unabhängig von der Subscription Art (Source initiated / Collector Initiated) oder von den Einstellungen die man bei der Subscriptionerstellung auswählen kann. Die Event-Details der weiterlgeleiteten Events erscheinen nicht wie auf dem Quellrechner sondern manche Parameter werden nur als Prozentzeichen angezeigt (%). Siehe Screenshot unten: Um den Fehler zu beheben, bitte folgende Einstellungen verändern: Umstellung der Sprache innerhalb der Subscription-Einstellungen als auch das Format des Benutzers. Konfiguration via: Wecutil ss /l:en-US wecutil ss /cf:RenderedText Als auch: Control Panel -> Region Die Einstellung muss auch für das System-Konto übernommen werden. Dies kann auch über Registry erreicht werden indem under dem RegKey HKEY_USERS\S-1-5-20\Control Panel\International untere Werte gesetzt werden: Danach sollten die weitergeleiteten Events richtig angezeigt werden. Viele Grüße, Carmina

Basic Theme Corrupt Server 2012+

msft.cadumi — Thu, 25 Feb 2016 01:13:26 GMT

Hallo, heute möchte ich euch ein einfachen Workaround zum Thema korrupte Windows Basic-Theme vorstellen. [Szenario] =========== - Ein Benutzer mit einem hohes Kontrast - Thema verwendet, verwendet eine Remote App auf einem Terminal Server -Nachdem er sich einmeldet wird das Basic Theme auf dem Terminal Server auch als hohes Kontrast angezeigt, obwohl das nicht eingestellt ist. -Desktop Experience Rolle ist auf den Server nicht installiert -Dies gilt dann sowohl lokal auf dem Terminal Server als auch für alle anderen Benutzer die sich auf dem Terminal Server einmelden Alles sieht dann folgenderweise aus: Lösung: Full Ownership des Folders C:\Windows\Resources\Themes\aero\VSCache übernehmen. Versteckte Dateien anzeigen. Dann werden folgende 2 Files sichtbar: “C:\Windows\Resources\Themes\aero\VSCache\aerolite.msstyle_1033_96.mss” “C:\Windows\Resources\Themes\aero\VSCache\aero.msstyle_1033_96.mss“ Bitte die beiden Dateien weglöschen Server neustarten Die 2 Dateien werden sich wieder herstellen Problem sollte dadurch behoben sein Viele Grüße, Carmina

[PRINT] Empfohlene Druckermigration von Windows 2003 SP2 32-bit auf Windows 2008 R2 / 2012 Druckserver

Cezar Poenaru — Fri, 15 Jan 2016 04:36:00 GMT

Die Idee hinter unserer Empfehlung ist von einem Windows 2003 SP2 Druckserver nur die Druckerqueues zu migrieren, ohne noch die alten Treiber, Print Prozessoren und Monitore mit zu migrieren.
Die Druckerqueues werden, beim Import auf Windows 2008 R2, die neuen Druckertreiber übernehmen, anhand der Configuration File.

1. Erstens muss eine Liste der Druckertreiber erstellt werden.
Danach muss überprüft werden welche Druckertreiber mit aktuellen/kompatiblen Versionen ausgetauscht werden.

2. Die Konfiguration auf Windows 2008 R2 soll, nach der Drucker Migration, folgendermassen aussehen:

Generic01 und HP01 sollen die gleichen Treiber behalten, Generic / Text Only und HP Business Inkjet 2200/2250 (HPA)
HP02, HP03 und HP04 sollen den neuen Universal Printing PCL 6 (v5.5.0) bekommen.

3. Die nötigen Treiber müssen zuerst auf dem Windows 2008 R2 installiert werden.
Die x86 Versionen der gleichen Treiber müssen remote über Print Management von einem x86 Windows Client übertragen werden.

Da es hier um einen Windows 2008 R2, wird ein 32-bit Windows 7 Client benötigt.
Auf dem Windows 7 Client werden die nötigen x86 Treiberversionen zuerst installiert.

Danach wird durch Print Management der Windows 2008 R2 Druckserver hinzugefügt:

4. Nun wird unter dem Windows 2008 R2 das Feld Drivers angeklickt um zu überprüfen ob die Treiber auf dem Server wiedergegeben werden.
Auf dem Windows 2008 R2 Druckserver ist als Beispeil der x64 HP Universal Printing PCL 6 schon installiert und die x86 Version wird benötigt.
Die nötige x86 Version kann folgenderweise vom einem 32-bit Client der gleichen Generation mit dem Print Server (Bsp: Windows7 – 2008 R2) auf dem Server installiert werden:

[Print Management > Print Servers > Print Server > Drivers > Context Menu > Add Driver]

> Hier wird nur x86 ausgewählt:

> Der DriverStore des Windows 7 wird geöffnet und der nötige x86 muss ausgewählt werden:

> x86 Treiberdateien werden von Client auf dem Druckserver kopiert:

5. Nach der Installation der nötigen x86 und x64 Treiber wird auf dem Windows 2008 R2 Druckserver überprüft ob alle vorhanden sind:

6. Von Windows 7 Client oder Windows 2008 R2 Server wird durch PrintBRM eine –NOBIN Backup Datei der Druckerqueues von Windows 2003 SP2 Druckserver erstellt.

Es wird alles migriert außer den Treibern.

> printbrm –B –S –F -nobin

Beispiel: > printbrm –B –S 04win2k3 –f C:\Prbackup\04win2k3 - nobin

> Es müssen keine Fehlermeldungen erscheinen.

7. Wie im folgendem Blog beschrieben wird eine DRVMAPPING.XML Datei erstellt: https://blogs.technet.com/b/askperf/archive/2009/02/20/two-minute-drill-printbrm-and-the-configuration-file.aspx
Diese kann ganz einfach mit Notepad erstellt werden.

Folgender Parameter muss mit dem alten und neuen Treiber erstellt werden:

8. Datei als DRVMAPPING.XML abspeichern.

9. Nun sind die nötigen Dateien erstellt: Backup Datei der Druckerqueues (04win2k3) und die Konfigurationsdatei (DRVMAPPING.XML).

10. Migration der Druckerqueues mit der Backup Datei und Konfigurationsdatei durch PrintBRM durchführen:

> printbrm –R –S –F –C

Beispiel: > printbrm –R –S 05win2k8r2 –F c:\prbackup\04win2k3 –C c:\prbackup\drvmapping.xml

- Falls PrintBRM die Drucker schon bei der Migration ins AD freigeben soll dann muss noch einer der folgenden Parameter in der oberen Cmdlet hinzugefügt werden: “–P ALL“ oder “-P ORIG“:

! Es werden Fehlermeldungen erscheinen für die Treiber welche nicht mehr benutzt werden:

11. Nach der Migration wird auf dem Windows 2008 R2 Druckserver überprüft ob alle Druckerqueues importiert wurden und ob der richtige Druckertreiber zugewiesen wurde.
Danach werden die Druckerqueues auf Ihre Funktionalität überprüft: Einstellungen, Testdruck usw.

Druckerqueues auf Windows 2008 R2:

Treiber auf Windows 2008 R2 – keine Treiber vom Windows 2003 SP2 wurden auf den neuen Druckserver importiert:

Druckerqueues benutzen den Print Prozessor zugewiesenen Druckertreiber:

Dieser Beitrag verleiht keinerlei Garantie oder Rechte.
This contribution does not grant any warranty or rights.

Cezar Poenaru
Support Engineer - Platforms Core Team

--- Disclaimer ---/
This posting is provided "AS IS" with no warranties, and confers no rights.

The entire risk arising out of the use or performance of the sample scripts and
documentation remains with you. In no event shall Microsoft, its authors, or
anyone else involved in the creation, production, or delivery of the scripts be
liable for any damages whatsoever (including, without limitation, damages for
loss of business profits, business interruption, loss of business information,
or other pecuniary loss) arising out of the use of or inability to use the
sample scripts or documentation, even if Microsoft has been advised of the
possibility of such damages.
--- Disclaimer ---\

[Kurz erwähnt] Nach der Aktivierung von Code Access Security lässt sich die Powershell nicht mehr starten

Matthias Meiling [MSFT] — Thu, 07 Jan 2016 04:34:00 GMT

Hallo,

aus Kompatibilitätsgründen wurde von einem Kunden temporär die Code Access Security (CAS) auf einem Windows 2012 R2 Server auf LegacySecurityPolicy umgestellt.

Die Konfiguration erfolgte system-global über die Konfigurationsdateien c:\Windows\Microsoft.NET\Framework\\Config\machine.config respektive
c:\Windows\Microsoft.NET\Framework64\\Config\machine.config unter Verwendung von .

Im Anschluss wurde festgestellt, dass sich keine .NET-Anwendungen mehr öffnen lassen.

Fehlermeldung:
The shell cannot be started. A failure occurred during initialization:
The type initializer for 'System.Management.Automation.SessionStateScope' threw an exception.

Das Problem trat nur auf Windows Server 2012 R2 auf – nicht unter Windows Server 2008 R2.

Nach kurzer Prüfung wurde festgestellt, das NetFx40_LegacySecurityPolicy nur auf Anwendungsebene konfiguriert werden kann (via Manifest-File).

Viele Grüße,
Matthias Meiling

This posting is provided "AS IS" with no warranties, and confers no rights.

The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.

[Kurz erwähnt] Windows 8.1 – Einspielung von Systemabbildsicherung schlägt fehl - 0x80042412

Matthias Meiling [MSFT] — Tue, 05 Jan 2016 03:35:00 GMT

Hallo,

heute möchte ich über eine schnelle Lösung zu einem Backup-Problem schreiben.

Problem:
OS Windows 8.1
Systemabbildsicherung wurde erstellt (Systemsteuerung > Dateiversionsverlauf > Systemabbildsicherung).

Nach einem Hardwaredefekt sollte das Backup auf einem anderen System (identische Hardware) über die Windows Recovery Optionen wieder eingespielt werden.

Hierbei trat bei der Ausführung des Backups der folgende Fehler auf:

Fehler beim Ausführen des Wiederherstellungsvorgangs.
In den Details wurde auf den Fehlercode 0x80042412 verwiesen.

Das Problem trat nur auf bestimmten Hardware-Typen auf.

Lösung (Lösungsorientiert):

Wir haben die Systemdisk geleert und das Backup im Anschluss via WBAdmin zurückgespielt.

Step by Step - um die Disk zu leeren (über die Recovery-Console):

Diskpart.exe
List disk
Select disk
Clean
exit

Achtung:
Hierdurch werden alle Partitionen auf der jeweiligen Disk gelöscht.
Bitte sicherstellen, dass keine benötigen Daten ggf. auf anderen Partitionen liegen und auch sicherstellen, dass es sich nicht um die Backup-Disk handelt.

Einspielung des Backups (ebenfalls über die Recovery-Console)

Version des Backups ermitteln:

Wbadmin get versions -backuptarget:d:
[Backup-Speichermedium entsprechend anpassen, in meinem Beispiel liegt es auf D]

Ausgabe (von meinem System):

Wbadmin start sysrecovery -version -backuptarget:d: -recreatedisks

Beispiel:

Die Wiederherstellung ist im Anschluss durchgelaufen.

Viele Grüße,
Matthias Meiling

Memory Leak verursacht von dem Remote Registry Dienst unter Windows 8, 8.1 und Server 2012, 2012R2

msft.cadumi — Fri, 26 Jun 2015 06:49:12 GMT

[Deutsch] Szenario:

Unter unbewussten Situationen kann es dazu kommen, dass nach 10 Minuten nachdem das System hochgefahren wird, ein Memory Leak stattfindet.

Ursache dafür kann der Remote Registry Dienst sein.

Seit Windows 8, ist das Verhalten für den Remote Registry, by design so, dass dieser nach 10 Minuten Inaktivität gestoppt wird, nachdem die Verbindung den Idle Status erreicht.

Ein KB Artikel existiert schon, ist leider nur auf Japanisch verfügbar:

https://support.microsoft.com/en-us/kb/2921969/ja

Im Task Manager kann man bemerken, dass der Remote Registry Dienst und dessen svchost.exe nicht sehr viel Speicher verwendet zB:

Auch wenn man das Service in einem selbständigen svchost.exe isoliert – wird nicht angezeigt, dass dieser viel Speicher verbraucht.

Man kann aber bemerken, dass der verfügbare Speicher ständig absinkt, bis die Maschine einfriert.

Wenn man den Remote Registry Dienst stoppt, steigt der Speicher nicht mehr an, sondern bleibt konstant, bei dem Wert bei dem es sich letztens befand.

Nur ein Neustart des Systems würde den Speicher wieder in den normalen Grenzen bringen.

Workaround:

=============================

Setzen sie folgenden RegistryWert:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\RemoteRegistry\DisableIdleStop

Auf den Wert 00000001

Als Default Wert ist die 00000000 eingerichtet.

============================

Damit steigt der Speicherverbrauch durch den RemoteRegistry Service nicht mehr an.

[Englisch] Szenario:

Under unknown circumstances, you may encounter the issue, that after approximately 10 Minutes System Up-time a Memory Leak occurs.

The cause of this might be the Remote Registry Service.

Starting with Windows 8 and newer OS systems, the behavior of the Remote Registry service is designed to stop once the 10 minutes idle connection has been reached.

A KB article is already available, unfortunately only in Japanese:

https://support.microsoft.com/en-us/kb/2921969/ja

You can notice in task manager, that the Remote Registry and the hosting svchost.exe are not necessarily consuming lots of memory:

Even after isolating the service in his own svchost.exe - you cannot see the high consumption.

What can be observed, are the available GB which are constantly decreasing until the system hangs.

If the Remote Registry service is being stopped, the Memory will remain constant and not sink back to normal. This will happen only after a system restart.

The current analysis have shown, the root cause is a error in the Endpoint Mapper Logic component.

As there was a easy workaround found, we predict that there will be no fix published, but the issue will be resolved in future OS systems.

Workaround:

=============================

Set the below Registry Key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\RemoteRegistry\DisableIdleStop

set on: 00000001

As default 00000000 is selected.

============================

Applies for:

Windows 8
Windows 8.1
Windows Server 2012 Datacenter
Windows Server 2012 R2 Datacenter
Windows Server 2012 R2 Standard
Windows Server 2012 Standard

Happy Troubleshooting

Thanks,

Carmina

BitLocker Network Unlock

Matthias Meiling [MSFT] — Fri, 15 May 2015 06:41:00 GMT

Hallo,

seit Windows Server 2012 respektive Windows 8 stellt Microsoft eine neue Möglichkeit bereit, um die BitLocker-Entsperrung (Unlock) weitergehend zu vereinfachen - BitLocker Network Unlock.

Network Unlock verwendet den TPM+PIN Protector. Ist BitLocker Network Unlock aktiviert und das System mit dem Unternehmensnetzwerk verbunden (in dem Network-Unlock eingerichtet wurde), muss während des Starts keine PIN eingegeben werden (solange der TPM keine Veränderungen der Umgebungsparameter feststellt). Die Autorisierung erfolgt in diesem Fall mittels Public/Private-Zertifikat (anstatt der PIN). Ist das System jedoch nicht mit dem Netzwerk verbunden, muss eine PIN eingegeben werden.

Diese Möglichkeit ist insb. für Server-Systeme interessant, für die nur ein geringeres physikalisches Zugriffsschutz-Niveau gegeben ist (bspw. kleine Niederlassungen / Shops …). Wird das System „entführt“, kann der „Servernapper“ nicht auf die Daten zugreifen.

Wie funktioniert Network Unlock?

Wie bereits beschrieben, setzt Network Unlock auf den Protector TPM+PIN auf.

Beim Start stellt der Windows Boot-Manager fest, dass ein Network Unlock Protector vorhanden ist.

Ähnlich wie bei PXE sendet der DHCP-Treiber im Anschluss ein Broadcast Paket um eine IP-Adresse zu erhalten.

Nachdem dies geschehen ist, wird ein sogenannter hersteller-spezifischer DHCP-Request gesendet, welcher eine Sitzungs-ID und einen Netzwerk-Key beinhaltet und mittels öffentlichen Zertifikatsschlüssel verschlüsselt ist. Der Network Unlock Provider (basierend auf WDS) erkennt dieses Paket - und sendet eine via Private-Key verschlüsselte Antwort zum Client zurück - woraufhin der Boot-Vorgang fortgeführt wird - eine Interaktion des Benutzers ist in diesem Fall nicht notwendig.

Funktioniert Network Unlock nicht (bspw. System ist nicht mit dem Netzwerk verbunden), muss die TPM PIN eingegeben werden.

Hinweis:
Network Unlock hat keine Auswirkung auf das Recovery-Verhalten des TPM.

Welche Anforderungen müssen gegeben sein?

Clientseitig:
OS ab Windows 8 (64-Bit) resp. Server 2012 R2 mit TPM und SecureBoot aktiv
UEFI Firmware 2.3.1 mit DHCP-Treiber im native Modus

Serverseitig:
Einen Server mit installierten Windows Deployment Services (+ Network Unlock)

Einen separaten Server als DHCP-Server

Optional eine CA.
Theoretischen kann auch mit Selbst-Signierten Zertifikaten gearbeitet werden.

Bei meiner Anleitung gehe ich von den folgenden Gegebenheiten aus:

Einen Windows 2012 R2 Server - Nachfolgend WDS Server genannt
WDS-Rolle ist installiert und Grundkonfiguration wurde vorgenommen, so dass dieser gestartet ist.

Einen Windows 2012 R2 Server - Nachfolgend DHCP Server genannt
DHCP-Rolle ist installiert und wurde konfiguriert (DHCP-Server vergibt IP-Adressen - gleiches Subnet wie der WDS-Server)

Eine Windows Zertifizierungsstelle (CA)
Kann ggf. auf einen der Server oder einem separaten Server installiert werden / laufen.

Einen Windows 8.1 Client der die o.g. Anforderungen erfüllt
* Es kann natürlich auch Windows Server 2012 resp. Windows 8 verwendet werden

Installation

Vorab - getreu dem Motto "Ein Bild sagt mehr als tausend Worte" - setze ich primär auf Abbildungen und kommentiere nur wenige Punkte.
Ich hoffe, dass die Beschreibung ausführlich genug ist.

Aktion 1 - Einrichtung der Zertifikatsvorlage [CA]

Für Network Unlock wird eine spezielle Zertifikatsvorlage benötigt. Bitte gehen Sie für die Erstellung folgendermaßen vor:

Öffnen Sie die CA, gehen Sie auf Templates und öffnen Sie die Template-Verwaltung.

Duplizieren Sie im Anschluss das Template Benutzer.

Konfigurieren Sie dies wie nachfolgend dargestellt:

Bestehenden Richtlinien löschen und eine neue hinzufügen:

[hier zum Copy&Paste] 1.3.6.1.4.1.311.67.1.1

[Kleiner Nachtrag]

Im Anschluss die neue Vorlage speichern und die Template-Verwaltung schließen.

Nun muss die Zertifikatsvorlage noch veröffentlicht werden:

Aktion 2 - Installation des Network Unlock Features [WDS-Server]

Bitte öffnen Sie auf dem WDS-Server den Servermanager und installieren Sie das BitLocker Network Unlock Feature.

Aktion 3 - Anforderung des Zertifikats und Einrichtung von Network Unlock [WDS Server]

Öffnen Sie auf dem WDS-Server eine MMC und fügen Sie das Zertifikats-SnapIn hinzu (zwei Mal -einmal für Ihren Benutzer - einmal für den Computer).

Fordern Sie dann über den Benutzer-Store das Zertifikat an.

Das Zertifikat muss im Anschluss 2-Mal exportiert werden - einmal mit privaten Schlüssel (.PFX) / einmal ohne (.CER).

Für das Zertifikat mit privaten Schlüssel:

Hinweis: Ich habe die Einstellung auf Standard belassen.
Im nächsten Dialog muss noch ein Passwort eingegeben und das Zertifikat gespeichert werden.

Für das Zertifikat ohne privaten Schlüssel:

Sie sollten nun zwei Dateien haben - einmal .CER und .PFX.

Nun muss das Zertifikat mit dem privaten Schlüssel (PFX) im Computer-Store / Network Unlock importiert werden.

Im Anschluss den Import bestätigen - das Zertifikat sollte dann gelistet werden:

Das Zertifikat ohne privaten Schlüssel (CER) wird im nächsten Schritt benötigt.

Aktion 4 - Einrichtung der GPO-Einstellung

Ich habe hierzu eine neue GPO angelegt, welche die folgenden Einstellungen beinhaltet:

Hinweis:
Da es sich bei mir nur um eine Testumgebung handelt, habe ich die einfachste Konfiguration gewählt. Die gezeigten Einstellungen müssen so gesetzt werden - alle anderen Einstellungen können Sie gem. Ihren eigenen Anforderungen festlegen. Ich empfehle Ihnen unbedingt die Einstellungen für das Recovery vorzunehmen (was jedoch nicht Bestandteil dieses Artikels ist).

Um das Zertifikat auszurollen (ich hatte dies über die gleiche GPO gemacht) bitte das Zertifikat ohne privaten Schlüssel importieren.

Nun die GPO noch zur OU linken, in der sich die Clients befinden und das Einrichten von Network Unlock ist abgeschlossen.

Aktion 5 - Testen

Nachdem die Einstellungen Clientseitig appliziert wurden und BitLocker aktiviert wurde, sollten Sie den Protector sehen:

Wenn nun alles funktioniert hat und Sie das System neustarten (und das System mit dem Netzwerk verbunden ist), sollte keine PIN abgefragt werden.

Falls das nicht der Fall ist - einige Hinweise fürs Troubleshooting:

Prüfen Sie, ob der Client via PXE eine IP-Adresse bekommt.

Ändern Sie im BIOS testweise die Bootreihenfolge, so das Netzwerk an erster Stelle steht (wird eigentlich nicht benötigt - aber manchmal braucht der DHCP-Treiber im UEFI einen Klapps :-) ).

Für DHCP / WDS entsprechend die Debug & Analytic Eventlogs bzw. Netzwerk-Trace verwenden.

Ich hoffe, dass die bereitgestellten Informationen weiterhelfen und wünsche ein schönes Wochenende.

Viele Grüße,
Matthias Meiling
Premier Platforms Core Team | Microsoft

PS: Unser offizieller Artikel zu diesem Thema als Referenz
https://technet.microsoft.com/de-de/library/jj574173.aspx

[Surface] [DE/EN] Surface Pro 3 Best Practices

Cezar Poenaru — Fri, 15 May 2015 02:49:00 GMT

Info: Blogeintrag wird periodisch aktualisiert. Deutsch: Hallo zusammen, Heute möchte ich über ein paar Best Practices für Surface Pro 3 sprechen, vor allem in der Enterprise Umgebung. Firmware und Treiber: Wir empfehlen die Firmware und Treiber des Surface Pro 3 Gerätes immer auf dem aktuellsten Stand zu halten, da mit der Zeit verschiedene Bugs und Performanceprobleme dadurch gefixt werden. Unter folgendem Link können diese online gefunden und heruntergeladen werden: https://www.microsoft.com/en-us/download/details.aspx?id=38826 Die Datei "SurfacePro3_150501.msi" ist ein Installationspacket welches die Installation der Firmware und Treiber erleichtert, da diese nicht mehr einzeln installiert werden müssen. Die Datei "SurfacePro3_150501.zip" bietet gegenüber nicht eine leichte "One-Click" Möglichkeit die Firmware und Treiber alle auf einmal automatisiert zu installieren. Diese müssen aus dem Zip-Archiv einzeln installiert werden. Firmware und Treiber Updates werden selbverständlich auch über Windows Updates mit den Namen "System Firmware Update" oder "System Hardware Update" durchgeschleust. Eine genaue Verlaufliste der Firmware und Treiber Updates und was genau gefixt oder geändert wurde, kann unter folgendem Link gefunden werden: Surface Pro 3 update history - https://www.microsoft.com/surface/en-us/support/install-update-activate/pro-3-update-history ! Es ist empfehlenswert für die Surface Pro 3 Geräte in der Enterprise ein neues Custom Windows Image zu bauen, anstatt schon ein bisheriges generelles Image zu benutzen, da verschiedene Probleme auftauchen können, wie z.B. Bluescreens, Hangs, Energieprobleme usw. Hier noch ein interessanter Blog Artikel welches die neuen UEFI Möglichkeiten in der Enterprise beschreibt: https://blogs.technet.com/b/surface/archive/2015/03/26/improvements-to-your-surface-pro-3-devices.aspx Storage Treiber: Es gibt Situationen wo der Intel Storage Treiber iastora.sys auf den Surface Pro 3 Geräten benutzt wird. Der iastora.sys Treiber ist mit Surface Pro 3 nicht kompatibel und soll nicht benutzt werden. Für den Fall dass dieser Treiber auf dem Surface Pro 3 Gerät benutzt wird, muss dieser mit dem storahci.sys Treiber aus dem Surface Pro 3 Treiberpacket ausgetauscht werden: Hotfixes: Wir empfehlen (Stand 15.Mai.2015) auf dem Surface Pro 3 Gerät noch folgende Hotfixe zu installieren, welche Bugs und Performanceprobleme korrigieren und vor allem, die Laufzeit des Gerätes verbessern: - November 2014 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2: https://support.microsoft.com/en-us/kb/3000850/ - December 2014 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2: https://support.microsoft.com/en-us/kb/3013769/ - Improvement that saves battery power on a Windows 8.1 or Windows Server 2012 R2-based computer: https://support.microsoft.com/en-us/kb/2955769/ - Surface Pro 3 doesn't hibernate after four hours in connected standby: https://support.microsoft.com/en-us/kb/2998588/ - Windows 8.1 or Windows RT 8.1 restarts two times after it installs a firmware update: https://support.microsoft.com/en-us/kb/2969817/ - Stop error when a Surface Pro 3 that's running Windows 8.1 awakens from Sleep mode: https://support.microsoft.com/en-us/kb/3051476/ - Surface Pro 3 and Surface Pro 2 do not successfully connect to a wireless display session by using a Miracast receiver: https://support.microsoft.com/en-us/kb/3052469/ - USB devices drain battery fast on a computer that is running Windows 8.1 or Windows Server 2012 R2: https://support.microsoft.com/en-us/kb/3046465 - Intermittent problems occur while peripherals are attached to a Surface Pro 3 device: https://support.microsoft.com/en-us/kb/3087655 - STOP Error 0x0000009F in DRIVER_POWER_STATE_FAILURE on Windows 8.1 when your computer resumes from sleep mode: https://support.microsoft.com/en-us/kb/3029803 - Network adapters may not connect after you resume a Windows-based computer that is out of docking station range: https://support.microsoft.com/en-us/kb/3080734 - Stop error code 0xD1, 0x139, or 0x3B and random crashes in Windows Server 2012 R2: https://support.microsoft.com/en-us/kb/3055343 - Computer crashes or restarts unexpectedly when it's resumed from sleep mode in Windows: https://support.microsoft.com/en-us/kb/3102242 Energieoptionen und Connected Standby/Hibernate auf Win8.1: Surface Pro 3 benutzt Connected Standby/InstantGo und verhält sich diesbezüglich nicht wie die traditionellen Geräte welche nur Sleep, Hibernate benutzen. Diesbezüglich muss man auf einige Sache aufpassen um nicht auf Performanceprobleme oder Energieprobleme zu stoßen. Unter folgendem Link gibt es eine Beschreibung des Connected Standbys und dessen Verhalten: Introduction to Connected Standby: https://download.microsoft.com/download/5/D/1/5D167007-01CF-4977-9F82-5FEEEA4C9FDB/introduction-to-connected-standby.docx Connected Standby bringt das Standby-Verhalten der Smartphones auf 32-bit/64-bit Windows Systemen. Es ermöglicht ein sofortiges An- und Ausschalten des Gerätes und somit eine bessere User Experience wie auf den Smartphones. Die CS Funktionalität ermöglicht dass das Gerät immer verbunden bleibt und Modern Apps (wenn diese für CS programiert wurden) und Dienste immer aktualisiert bleiben und während des CS-Modus funktionieren können. Die Energieverwaltung unterscheidet sich grundlegend im Vergleich zum den traditionellen ACPI Sleep (S3) und Hibernate (S4) und bietet mehrere Vorteile an. Eines dieser Vorteile ist das sofortige Aufwachen des Gerätes. Das Aufwachen aus dem Connected Standby ist in diesem Sinne in der Regel viel schneller als Sleep (S3) und deutlich schneller als Hibernate (S4) und Shutdown (S5). Beim Aufwachen des Gerätes aus dem Connected Standby muss das Gerät die Wi-Fi Verbindung nicht mehr wiederherstellen, welches den Vorteil hat dass verschiedene Modern Apps schneller geladen werden können. Zusätzlich haben die Geräte die Möglichkeit den Anwender während des Connected Standby auf neue E-Mails und ankommende Skype Anrufe zu informieren. Die Wi-Fi Funktionalität bleibt während des Connected Standby in einem geringem Stromverbrauchsmodus eingeschaltet und kann sich automatisch zu verschiedenen Access Points verbinden, je nachdem wie die Wi-Fi Einstellungen gesetzt sind. Zum Bespiel, wenn der Anwender den Standort wechselt und die nötigen Wi-Fi Einstellungen gesetzt sind, dann wird sich das Gerät automatisch an den jeweiligen Access Point im neuem Standort während des CS-Modus verbinden. Hier muss gesagt werden dass die Wi-Fi Verbindung nicht permanent an ist, sondern in einem Standby Modus, wo in der Regel alle 15 Minuten (falls angefordert) diese aufweckt um Apps und Dienste zu aktualisieren. Sleep und Hibernate pausieren komplett alle Aktivitäten auf traditionellen Geräten. Die Aktivitäten werden erst wiederhergestellt wenn der Anwender das Gerät durch den Power-Knopf, die Tastatur/Maus, dem Touchpad wieder aufweckt oder auch durch geplannte Wake Timers. Connected Standby dagegen automatisiert den Verlauf der Aktivitäten während des Sleeps, damit regelmäßig Aktualisierungen durchgeführt werden. Die Anzahl der Aktivitäten/Aktualisierungen während des Connected Standby wird vom System eng kontrolliert damit geringer Stromverbrauch und eine lange Batterielebensdauer sichergestellt wird. Nach 4 Stunden im Connected Standby Modus wechselt das Gerät automatisch auf Hibernate. Dies geschieht automatisch und Hibernate kann zurzeit nicht auf andere Werte konfiguriert werden. - Die Deaktivierung von Connected Standby ist auf Surface Pro 3 nicht supported. - Die Benutzung der Erweiterten Energieoptionen auf Windows 8.1 ist ebenfalls nicht supportet (Windows 10 bietet für die Surface Geräte zusätzliche Energieoptionen an als Windows 8.1) - Hibernate (Default: Nach 4 Stunden CS) kann auf Surface Pro 3 Geräte mit Windows 8.1 auf andere Werte nicht konfiguriert werden (Hibernate kann ab Windows 10 auf andere Werte konfiguriert werden) - Surface Pro 3 wird nach 4 Stunden CS nicht auf Hibernate wechseln, wenn das Gerät angedockt ist. Dies ist by Design. - Bezüglich der Energieoptionen müssen die konfiguriert werden welche für SP3 im Connected Standby verfügbar sind (Balanced Powerplan), da die erweiterten Energieoptionen keine Wirkung haben werden oder verschiedene Probleme auslösen können. Datum/Uhrzeit wird auf Surface Pro 3 Geräten mit Windows 8.1 falsch angezeigt: Auf Surface Pro 3 Geräten mit Windows 8.1 kann es vorkommen dass Datum und Uhrzeit falsch angezeigt werden, wenn die Geräte in der Domäne verbunden sind. Dieses Problem ist bei Microsoft bekannt. Der TimeService korrigiert die Uhrzeit zu aggresiv. Diesbezüglich müssen für die Surface Pro 3 Geräte folgende Werte verwendet werden: Registrypfad: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config 1. UpdateInterval (Default: 30.000): Wert muss zwischen 100 und 30.000 ausgetestet werden. 2. PhaseCorrectRate (Default: 1): Wert muss auf mindestens 4 oder höher eingestellt werden. 3. MaxAllowedPhaseOffset: Wert muss zwischen 100 und 300 eingestellt werden. Surface Pro 3 Dockingstation und Surface Dock: Wenn es zu technischen Problemen in Verbindung mit der Surface Pro 3 Dockingstation oder der Surface Dock kommt, ist es empfehlenswert folgende Schritte durchzuführen: 1. Aktuelles Firmware-/Treiberpacket soll auf dem Surface Gerät installiert sein. Achtung: Die Surface Dock ist mit Surface Pro 3 erst kompatibel wenn mindestens das Firmware-/Treiberpacket von Oktober 2015 installiert ist. Die zuständige Komponente für die Kompatibiltät des Surface Pro 3 mit der Surface Dock ist: Surface Pro System Aggregator Firmware update (v3.9.750.0) 2. Überprüfen dass auch das der Treiber für den Surface Gigabit Ethernet Adapter auf das Surface Gerät installiert ist. Der Surface Gigabit Ethernet Adapter Treiber ist nähmlich nicht nur für die Surface Ethernet Dongles zu nutzen, sondern auch mit den Surface Dockingstations. English: Info: Blog entry will be updated periodically. Hi all, Today I want to talk about some Best Practices for Surface Pro 3 devices, especially for enterprise scenarios. Firmware and Drivers: We recommend to keep the firmware and drivers on the Surface Pro 3 devices always up to date, as with time there are different bugs and performance issues which are fixed for the device. You can find and download the latest firmware and drivers from the following link: https://www.microsoft.com/en-us/download/details.aspx?id=38826 The file "SurfacePro3_150501.msi is a full packaged MSI installer which makes the installation of the firmware and all required drivers a lot easier, since you don't have to install each one separately. The "SurfacePro3_150501.zip" archive on the other hand is not an "one-click" solution to install the firmware and all required drivers at once. The archive needs to be unpacked and all drivers need to be installed individually. Firmware and driver updates are of course also being channeled through Windows Updates with the names of "System Firmware Update" or "System Hardware Update". A complete history of all updates for and what was changed/fixed on SP3 can be found here: Surface Pro 3 update history - https://www.microsoft.com/surface/en-us/support/install-update-activate/pro-3-update-history ! If you are using the Surface Pro 3 in the enterprise, it is recommended that you set up a new Custom Windows Image, instead of using a general OS image, as this can lead to different technical issues, such as bluescreens, hangs, power issues etc. Here's also an interesting blog article which describes the new UEFI possibilities in the enterprise: https://blogs.technet.com/b/surface/archive/2015/03/26/improvements-to-your-surface-pro-3-devices.aspx Storage driver: There are situations where the Intel storage driver iastora.sys is being used on Surface Pro 3 devices. The iastora.sys driver is however not supported on Surface Pro 3 and should not be used. If however this driver is being used on a Surface Pro 3 device, we recommend to change it with the storahci.sys driver from the SP3 driver package: Hotfixes: We recommend (as of 15.May.2015) that you install the following hotfixes on the Surface Pro 3 devices, which will fix some known bugs and performance issues: - November 2014 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2: https://support.microsoft.com/en-us/kb/3000850/ - December 2014 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2: https://support.microsoft.com/en-us/kb/3013769/ - Improvement that saves battery power on a Windows 8.1 or Windows Server 2012 R2-based computer: https://support.microsoft.com/en-us/kb/2955769/ - Surface Pro 3 doesn't hibernate after four hours in connected standby: https://support.microsoft.com/en-us/kb/2998588/ - Windows 8.1 or Windows RT 8.1 restarts two times after it installs a firmware update: https://support.microsoft.com/en-us/kb/2969817/ - Stop error when a Surface Pro 3 that's running Windows 8.1 awakens from Sleep mode: https://support.microsoft.com/en-us/kb/3051476/ - Surface Pro 3 and Surface Pro 2 do not successfully connect to a wireless display session by using a Miracast receiver: https://support.microsoft.com/en-us/kb/3052469/ - USB devices drain battery fast on a computer that is running Windows 8.1 or Windows Server 2012 R2: https://support.microsoft.com/en-us/kb/3046465 - Intermittent problems occur while peripherals are attached to a Surface Pro 3 device: https://support.microsoft.com/en-us/kb/3087655 - STOP Error 0x0000009F in DRIVER_POWER_STATE_FAILURE on Windows 8.1 when your computer resumes from sleep mode: https://support.microsoft.com/en-us/kb/3029803 - Network adapters may not connect after you resume a Windows-based computer that is out of docking station range: https://support.microsoft.com/en-us/kb/3080734 - Stop error code 0xD1, 0x139, or 0x3B and random crashes in Windows Server 2012 R2: https://support.microsoft.com/en-us/kb/3055343 - Computer crashes or restarts unexpectedly when it's resumed from sleep mode in Windows: https://support.microsoft.com/en-us/kb/3102242 Power options and Connected Standby/Hibernate on Win8.1: Surface Pro 3 is using Connected Standby/InstantGo and therefor is not behaving as the traditional devices which are using only Sleep and Hibernate. This means that you need to take some things into consideration in order not to stumble on some performance or power issues. The following link describes the Connected Standby and its behavior: Introduction to Connected Standby: https://download.microsoft.com/download/5/D/1/5D167007-01CF-4977-9F82-5FEEEA4C9FDB/introduction-to-connected-standby.docx Connected Standby brings the standby behavior of smartphones on 32-bit/64-bit Windows devices. It enables an immediate turn on and turn off behavior of the devices, which grants a much better user experience as on smartphones. The CS functionality enables the devices to be always connected and that modern apps (if these are programmed to take advantage of the CS feature) and services to be always up to date when CS is being used. Power management differentiate itself fundamentally in comparison with the traditional ACPI Sleep (S3) and (Hibernate (S4) and offers more advantages. One of these advantages is that it enables you an instant wake-up of the device. Waking up the devices from Connected Standby is generally much more faster than Sleep (S3) und clearly faster than Hibernate (S4) or Shutdown (S5). On wake-up the device has not to reestablish the Wi-Fi connection, which has the advantage that different modern apps are synced much faster. Additionally the devices have the advantage that they can inform the users about new e-mails or incoming skype calls, while in Connected Standby. The Wi-Fi functionality remains active during Connected Standby in a minimal power usage and can connect automatically to different access points, depending on the configured Wi-Fi settings.
For example, if an user changes the location and the required Wi-Fi settings are configured, then the device will automatically connect to the next access point in the new location during CS. Additionally you need to know that the Wi-Fi connection is not permanently working during CS. It stays in a low powered standby mode and resumes every 15 minutes (if required) in order to sync apps and services. Traditional sleep and hibernate pause all activities completely on traditional devices. All activities are only resumed when the user wakes up the device using the power button, the keyboard/mouse, the touch pad or scheduled wake timers. Connected Standby however automates the process of activities during sleep in order to keep the device synced. The number of activities/synchronizations done during Connected Standby are strictly done by the system in order to use low power consumption and guarantee a longer battery time. After 4 hours of Connected Standby, the device enters into hibernation. This is done automatically and you can't configure hibernation to other/specific values. - Disabling Connected Standby on Surface Pro 3 is not supported. - Configuring and using advanced power options in Windows 8.1 is also not supported (Windows 10 offers additional advanced power options for Surface devices). - Hibernation (default: after 4 hours of CS) in Windows 8.1 cannot be configured to other/specific values. (Hibernation can be configured to other values starting with Windows 10). - Surface Pro 3 will not hibernate after 4 hours of CS if the device is docked. This is by design. You can only configure the basic power options (Balanced power plan) which are supported by Surface Pro 3, as the advanced power options will either not work or cause different types of issues.. Date/Time is incorrect on Surface Pro 3 devices with Windows 8.1: There is a known issue on Surface Pro 3 devices with Windows 8.1 where it can happen that the date/time is shown incorrectly, if the device is joined to the domain. This issue appears due to the TimeService which over corrects the time on these CS devices. The following settings help correct the issue: Registry path: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config 1. UpdateInterval (Default: 30.000): Value must be set between 100 and 30.000 . 2. PhaseCorrectRate (Default: 1): Value must be set to 4 or above. 3. MaxAllowedPhaseOffset: Value must be set between 100 and 300. Surface Pro 3 Dockingstation and Surface Dock: When you're having technical issues related to any of the Surface dockingstations, we recommend the following: 1. Check that the Surface device has the latest firmware/driver package installed. Attention: The Surface Dock is only compatible on the Surface Pro 3 if at least the October 2015 firmware/driver package is installed. The designated component for this compatibility is: Surface Pro System Aggregator Firmware update (v3.9.750.0) 2. Check that also the latest version of the Surface Gigabit Ethernet Adapter driver is installed on the Surface device. The Surface Gigabit Ethernet Adapter driver is not only for theSurface Ethernet Dongles responsible, but also for the Surface docking stations. Dieser Beitrag verleiht keinerlei Garantie oder Rechte. This contribution does not grant any warranty or rights. Cezar Poenaru Support Engineer - Platforms Core Team --- Disclaimer ---/ This posting is provided "AS IS" with no warranties, and confers no rights. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages. --- Disclaimer ---\

UNTERSCHIEDLICHE EINSTELLUNGEN ZWISCHEN PRINTSERVER UND VERBUNDENE CLIENTS

msft.cadumi — Thu, 14 May 2015 08:52:00 GMT

Hi Folks,

heute möchte ich Euch folgendes Szenario vorstellen und die Optionen die wir in einer solchen Situation hätten:

[Szenario DE]

Das Unternehmen stellt einen Printserver mit verschiedene Druckerqueues zur Verfügung. Alle Geräte sind standardmäßig auf schwarz-weiß eingestellt.

Die Benutzer verbinden sich an die Druckerqueues und anhand des gewünschten Dokumentes, drucken diese entweder schwarz-weiß oder farbig.

End User können in deren Userprofil einwandfrei Druckereinstellungen ändern und speichern. Da User häufig die Druckereinstellungen auf farbig einstellen und nicht zurück auf schwarz-weiß wechseln, führt dies zu hohem Farbtonerverbrauch was vielleicht zu Geldverluste führen kann.

Wenn ein User sich an einen Drucker verbunden hat und Einstellungen ändert, werden diese Änderungen dauerhaft im Userprofil gespeichert.

Die aktuellen Einstellungen für das Druckerobjekt werden in der Registry unter HKEY_CURRENT_USER\Printers\Connections\"Servername,Printername"\DevmodePerUser

HKEY_CURRENT_USER\Printers\Connections\"Servername,Printername"\Devmodes2

gespeichert (die Einstellungen die der Anwender definiert hat).

Gewünscht wäre aber, dass mit jeder neuen Anmeldung, sich die Druckereinstellungen wie auf dem Druckserver definiert, umändern – ohne irgendwelche Userinteraktion; Oder, die User sollten die Haupteinstellungen nicht verändern können.

==================================================================================

[Das Verhalten: By Design]

Wieso??? Microsoft kann den End Usern den Zugriff auf den Printer Preferences nicht verweigern. Jeder Benutzer kann selbst auswählen wie er Dokumente druckt.

===================================================================================

[Workarounds]

1. Weglöschen und neuverbinden der Netzwerkdrucker während jedem Logon + weglöschen der Per-User Devmode zuvor:

Ein Logoff Skript erstellen der die Devmodes weglöscht:

Reg Delete HKCU\Printers\DevModes2 /v "\\printserver\printer" /f

Reg Delete HKCU\Printers\DevModePerUser /v "\\printserver\printer" /f

2. Erstellen von 2 separaten Printer Queues (1 black&white, 1 Color). Für die black&white Queue sollte hier aber ein Drucker Treiber benutzt werden, der nur schwarz-weiß drucken kann. Diesen kann man von 3rd Party Lieferanten erhalten.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Hi folks,

Today I want to present the following scenario and possible workarounds for this situation:

[Scenario EN]

Your company is managing one or several print server with different print queues. All devices are set to print black&white by default.

End user connect to the printer queues and on the basis of the document they want to print, they either select black&white or color.

End users can properly change and save printer settings in their User Profile without any restrictions. Since users often set the printer settings on color and not go back to black and white, this can lead to high color toner consumption which perhaps can lead to loss of money to the company.

If a user has connected a printer and changed the settings, these changes are permanently stored in the user profile under:

HKEY_CURRENT_USER\Printers\Connections\"Servername,Printername"\DevmodePerUser

HKEY_CURRENT_USER\Printers\Connections\"Servername,Printername"\Devmodes2

Wanted would be that with each new login, the printer settings as defined on the print server remain the defaults also on the client – without any user interaction; or, the user should not be at all able to change the main settings.

==================================================================================

[The Behavior: By Design]

But why??? Microsoft cannot deny a user to access the printer preferences. Each End user is allowed to print every document in the way he desires.

===================================================================================

[Workarounds]

1. Delete and reconnect the Network Printer during each logon and delete the Per-User Devmode before.

Create a Logoff Script which deletes the Devmodes:

Reg Delete HKCU\Printers\DevModes2 /v "\\printserver\printer" /f

Reg Delete HKCU\Printers\DevModePerUser /v "\\printserver\printer" /f

2. Have 2 Printer Queues (1 black&white, 1 Color) and change the Print Driver that it only can print black&white for the first Case.

Happy Troubleshooting.

Thanks,

Carmina