Windows Server 2008 R2 mit x86 Druckertreibern

Es war mal wieder an der Zeit, dass ein aktueller PrintServer her musste. Da mittlerweile fast alles auf 64Bit umgestellt ist, lag die Lösung nahe einen Windows Server 2008 R2 zu nehmen und für die wenigen Clients, die noch ein 32Bit Betriebssystem haben die Treiber mit zu installieren. Bei HP Druckern war das alles kein Problem. Auf dem PrintServer schlummern nur die HP Universaltreiber PCL6 32 & 64Bit. Die Clients laufen ohne Fehler und alles ist schön performant.

Totaler Murks allerdings, wenn man keine HP Druckertreiber installieren möchte. So z.B. knallt der Kyocera Universal 32&64 Bit Treiber immer auf den Hammer mit der Meldung doch bitte das Geeignete Windows Medium einzulegen.
Tja, da Windows Server 2008 R2 aber keine 32 Bit Version hat, wird es etwas schwieriger…

Abhilfe schafft leider nur eins. Man muss ne Windows 7 32 Bit Installation irgendwo haben…

Workaround:

  1. Man gehe auf dem PrintServer zu „Start/Geräte und Drucker“
  2. Rechtsklick auf den dummen Drucker, welcher die 32Bit Installation verweigert und „Druckereigenschaften“ auswählen
  3. Anschließend auf den Reiter „Freigabe“ klicken und unten rechts auf „Zusätzliche Treiber“
  4. Nun setzt bei dem neuen Fenster den Haken bei x86
  5. Anschließend öffnet sich das allen bekannte Fenster „Treiber hinzufügen“. Sucht nach der ini für den 32Bit Treiber und wählt diese aus.
  6. Nun sollte folgende Fehlermeldung auftreten:
    Problem mit der ntprint für x86 (32bit) Treiber
  7. Nun sollte man mal nach der ntprint_ Datei suchen, die man aber dank der 64bit Architektur des Win2008 R2 Servers nicht findet 🙂
  8. Abhilfe schafft ein Win7 Client mit 32bit Architektur. Geht auf dem Win7 Client in de Ordner „C:WindowsSystem32DriverStoreFileRepository“
  9. Kopiert den kompletten Ordner „ntprint.inf_x86_neutral_XXXXXXXXXXXXX“ auf eine Partition die der Printserver erreichen kann.
  10. Bei Punkt 7 in dieser Liste navigiert zu dem kopierten Verzeichnis.

Das sollte es gewesen sein!

 

Langsames abarbeiten von Druckaufträgen bei zu viel protokollierten Einträgen

Manchmal kommt es vor, dass man sich das Druckerprotokoll doch ein wenig anschauen muss, um zum Beispiel herauszufinden, was denn überhaupt gedruckt wird und was eventuell Probleme bereitet…

 

Dafür ist es immer recht sinnvoll, in den Drucker- Eigenschaften des betroffenen Druckers unter dem TAB Erweitert den Haken bei „Druckaufträge nach dem Drucken nicht löschen“ zu setzten.

 

 

Vergisst man das aber wieder auszustellen, kann es schon einmal vorkommen, dass nach 1-2 Tagen das Protokoll bei ein paar Hundert oder Tausend Einträgen steht. Das Problem an der ganzen Geschichte ist, sobald das Protokoll etwas voller ist, können die neu ankommenden Druckaufträge nicht mehr so schnell verarbeitet werden.

Löscht man das Protokoll, gehen die Druckaufträge wieder schneller durch… ein schöner Bug, welcher einen doch recht gut nach der Ursache suchen lässt 🙂

MSSQL 2005 Bug beim Umbenennen eines Users oder Logins

Wenn man versehentlicher Weise mal einen User im Active Directory angelegt hat, wo der Name und der Anmeldename nicht ganz stimmt aber zudem schon alles in den restlichen Bereichen, wie CTI, Exchange, MS SQL usw. angelegt hat, dann „Prost Mahlzeit“ beim Umbenennen. Normalerweise gehe ich dann immer so vor, dass ich den User komplett überall herauslösche (AD, MSSQL, Exchange usw.) und anschließend einen neuen User erstelle… Warum ich das in diesem Fall nicht gemacht habe kann ich leider auch nicht mehr sagen… ich werde in Zukunft aber bei der sicheren LÖSCH-Variante bleiben :-).

Nun gut… nachdem ich also den User komplett umbenannt hatte und auch der Meinung war alle Stellen erwischt zu haben, stellte sich heraus, dass es beim Login in Microsoft Dynamics NAV (Basis ist ein SQL-Server 2005 SP2) Probleme gab. Der Login war immer noch der alte Benutzername, obwohl dieser im Management Studio schon aktualisiert wurde.

Ewiges Umbenennen und neu anlegen half nicht. Angezeigt wurde er mir bei der Suche im AD über den SQL richtig, klickt man aber auf OK, legte er den SQL-Login immer mit dem falschen Anmeldenamen an… Meine Herren!
Wie sich herausstellte, ist das ein Bug in der 2005er Version des Microsoft SQL Servers. 

 

Ab SQL Server 2005 SP2 gibt es einen Workaround:

Problembeschreibung:

The problem will be when trying to access/manipulate metadata since SQL Server will use the metadata (MD) copy of the NetBIOS name (i.e. the old name) and we won’t be able to identify the new name.

The root cause for this problem is the fact that SQL Server keeps a copy of the Windows NetBIOS user name in MD and we use this MD copy whenever a name-based operation on the user is made instead

of relying exclusively on the SID. 

This is a well known limitation of SQL Server and it has been there since Windows authentication was introduced (SQL Server 7 if I do remember). In SQL Server 2005 SP2 we introduced a mechanism that

allows you to rename the login and user to match the updated Windows name:

 

ALTER LOGIN [Old_Windows_name] WITH NAME = [New_Windows_name]
ALTER USER [Old_Windows_name] WITH NAME = [New_Windows_name]

 

As long as the SID in MD for [Old_Windows_name] matches the SID for [New_Windows_name], this operation should succeed and properly rename the principal login/user name in MD. For more information please refer to BOL:

http://msdn.microsoft.com/en-us/library/ms189828.aspx
http://msdn.microsoft.com/en-us/library/ms176060.aspx

 

Nachdem ich die oben beschriebenen Schritte vollzogen hatte, funktionierte der Login mit dem umbenannten User wunderbar…

Zwei Stunden später stand der User mit dem alten Loginnamen wieder in der SQL… WTH!
Ich glaube dies ist aber dem NAV zuzurechnen, da dieser auch komischerweise seine Logins mit dem SQL synchronisiert und dort scheinbar immer noch bei der alten SID den alten Loginnamen stehen hatte…

Fazit: An einem ruhigen Abend erst mal die Löschvariante vollzogen und nach 1,5 Stunden war der User komplett neu und sauber angelegt … in allen Applikationen.

Zentrale TerminalServer-Profile trotz Domänenvetrauenstellung nutzen

Wer schon einmal eine oder mehrere weitere Domänen an die Hauptdomäne eines Windows Netzwerkes angebunden hat, weiß das es viele kleine Sachen gibt, die man beachten muss.
Bei dem letzten Projekt hatten wir eine weitere Domäne für eine ausländische Niederlassung über eine Vertrauenstellung anbinden wollen. Die Benutzer sollten mit RemoteApps (Windows Server 2008 Terminal Services) an dem entfernten Hauptstandort arbeiten. Das Problem welches nun bestand war, dass sich das Benutzerkonto in einer anderen Domäne befindet, als der Computer (TerminalServer) an dem sich angemeldet wird.

Beispiel :
Benutzer ist in Domäne D-2
Computer ist in der Domäne D-1
Beide Domänen sind über eine Vertrauensstellung verbunden

Bei Anmeldung des Users aus der anderen Domäne (D-2), wurde dem Benutzer immer ein temporäres Profil auf dem TerminalServer (D-1) untergeschoben und man konnte dadurch natürlich keine Benutzereinstellungen tätigen und speichern.

Die Lösung ist aber denkbar einfach… sofern man weiß, wo die verantwortliche Policy zu finden ist:

Ort: Computer Konfiguration / Administrative Vorlagen / System / Gruppenrichtlinien
Name: „Gesamtstrukturübergreifende Benutzerrichtlinien und Servergespeicherte Benutzerprofile zulassen“

Erklärung der GPO (Windows Server 2003):

Lässt benutzerbasierte Verarbeitung von Richtlinien, servergespeicherte Profile und Benutzerobjektanmeldeskripts für gesamtstrukturübergreifende interaktive Anmeldungen zu.
Diese Einstellung ist für alle Benutzerkonten, die sich interaktiv an einem Computer in einer anderen Gesamtstruktur anmelden, wirksam, wenn eine domänenübergreifende oder gegenseitige Vertrauensbeziehung besteht.
Wenn Sie diese Einstellung nicht konfigurieren, – werden keine benutzerbasierten Richtlinieneinstellungen von der Gesamtstruktur des Benutzers angewendet, – erhalten Benutzer keine servergespeicherten Profile, sondern ein lokales Profil von der lokalen Struktur auf ihren Computer. Der Benutzer erhält eine Warnung und Meldung 1529 wird in das Ereignisprotokoll geschrieben. – wird die Loopback-Gruppenrichtlinienverarbeitung angewendet. Dies geschieht mit Hilfe von computerbezogenen Gruppenrichtlinienobjekten. – wird Meldung 1109 (Loopback wurde in Ersetzungsmodus aufgerufen) in die Ereignisprotokollierung geschrieben.
Wenn Sie diese Einstellung aktivieren, ist das Verhalten wie bei Windows 2000 Server-Produktfamilie, d.h. die Benutzerrichtlinie wird angewendet und ein servergespeichertes Profil wird vom der Vertrauensstruktur zugelassen.
Wenn Sie diese Einstellung deaktivieren, erhalten Sie das gleiche Verhalten wie wenn Sie sie nicht konfiguriert haben.

Diese Policy einfach auf dem TerminalServer aktivieren und schon funktioniert die Anmeldung des Benutzers aus der Domäne die per Vertrauensstellung angebunden ist, ohne dass dieser User ein temporäres Profil zugeordnet bekommt, welches bei der Abmeldung vom TerminalServer automatisch gelöscht wird.

Hinweis: Der Tipp kam von IOK und war GOLD WERT!
Hier der KB-Artikel dazu: http://support.microsoft.com/kb/910206/en-us