Entries tagged as Windows XP

SCCM: Build and Capture von Windows XP

Auch wenn das Thema seit Windows Vista und 7 nicht mehr allzu aktuell sein dürfte; ich muss aktuell immer noch einige PCs per SCCM 2007 mit Windows XP installieren. War anfangs ein wenig holprig wieder ein XP Build and Capture zu erstellen und verteilen.
Damit's Euch nicht auch so geht, hier ein Kurz-How To:

1. Kopiert die Windows XP Installations-CD (am besten gleich eine inkl. SP2 oder SP3) in einen Share auf dem SCCM (am besten nach "RemoteInstall\Images" <= dürfte Standard sein)
2. Wechselt in das kopierte Verzeichnis der Windows-CD und darin in den Ordner "SUPPORT\TOOLS" und entpackt die "DEPLOY.CAB" in ein Verzeichnis namens "sysprep".
3. Erstellt danach im SCCM eine neue Collection (z.B. Windows XP (Build and Capture))
4. Wechselt im SCCM in den Knoten "Software Distribution" und legt ein neues Package (z.B. Windows XP SPx 32-Bit) mit folgenden Einstellungen an:
4a. "This package contains source files" -- als Pfad/Ziel gebt Ihr hier den zuvor erstellten "sysprep"-Ordner an
4b. "Data Access" einfach voreingestellt lassen
4c. Stellt die "Sending priority" unter "Distribution Settings" auf "High"
4d. Fertig stellen
5. Fügt dem neuen Package jetzt den/einen Distribution Point hinzu (NICHT aber den BootPXE !)
6. Erstellt im nächsten Schritt unter dem Knoten "Operating System Install Packages" ein neues Package (z.B. Windows XP SPx 32-Bit) und gebt als Pfad/Ziel das Windows XP-Verzeichnis auf dem Share (s. Punkt 2) an.
7. Fügt auch hier wieder den/einen Distribution Point hinzu und lasst auch hier BootPXE wieder aus.

Jetzt folgt die Task Sequenz. Da wir ein "Build and Capture" anstreben, legen wir diese auch wie folgt an:

1. Legt eine neue Task Sequence an und wählt im Assistenten "Build and capture a reference operating system image" aus
2. Gebt dem Kind einen Namen und wählt als Boot Image ein vorhandenes aus (sofern Ihr schon welche angelegt habt ! ;-) ). Das Boot Image ist bitte nicht mit unserer Windows XP Kopie zu verwechseln und hat damit erstmal nichts zu tun ! Boot Images werden unter dem Knoten "Operating System Deployment/Boot Images" verwaltet.
3. Als Package wählt Ihr das erstellte Windows XP Package, tragt den Product Key und bei Bedarf ein Adminkennwort ein
4. Tragt eine Arbeitsgruppe ein. Wenn die Maschine später einer Domain beitreten soll, wird dies nachher in einer neuen Tasksequenz gemacht !
5. Wählt im nächsten Schritt das Config Manager Client Package aus (sofern Ihr schon eins angelegt hattet)
6. Wählt im nächsten Schritt das aus, was Ihr braucht/wollt
7. So auch hier
8. Die Auswahl des ConfigMgr package, das das Sysprep-Tool beinhaltet, fällt auf das in Schritt 4 erstellte Windows XP Package, das unter "Software Distribution" liegt
9. Füllt das letzte Feld im Assistenten nach Eurem Gusto aus und schließt diesen ab

Damit habt Ihr die Task Sequence und könnt loslegen.


WICHTIG ! Damit es nicht schon zu Beginn der Task Sequence zu einem Bluescreen auf dem betroffenen Rechner kommt, solltet Ihr vorher im BIOS die Datenträgereinstellung überprüfen.
Sollte hier der Eintrag "AHCI" für die Bootplatte eingetragen sein, ändert diesen zu "IDE", weil Windows XP mit der AHCI-Einstellung nichts anfangen kann und noch vor der Installation mit einem Bluescreen abschmiert.


Viel Spaß und Erfolg. :-)

Registerkarte "Einwählen" unter Windows 7 nicht mehr verfügbar

Nach der Installation der Remote Server-Verwaltungstools unter Windows 7 steht in der Benutzerverwaltung in der MMC im Snap-In "Active Directory-Benutzer und -Computer" die Registerkarte "Einwählen" in den jeweiligen Benutzereigenschaften nicht mehr zur Verfügung.
Dies ist kein Bug, sondern von Microsoft bewusst so gewollt.
Im Supportartikel KB975448 schreibt MS:

QUOTE:
Dieses Problem tritt auf, weil im Manifest der Remoteserver-Verwaltungstools (RSAT) und im Installationspaket die Module "Rasuser.dll" und "Rtrfiltr.dll" nicht enthalten sind, die zum Laden der Registerkarte Einwählen benötigt werden.


Die Lösung: per RDP oder Telnet auf einen Windows 2008 Server verbinden, die MMC starten und dort die DialIn-Rechte für den jeweiligen Benutzer einstellen.
Super !
Das bedeutet aber auch, dass Zugriffsrechte auf den jeweiligen Server gewährt werden müssen, was ich nicht unbedingt für vorteilhaft halte, wenn einzelne Mitarbeiter auf einem Server herumfuhrwerken ! Dafür kann man sich schließlich die MMC mit dem gewünschten Snap-In auf dem jeweiligen PC einrichten.
Spitzen Idee von Microsoft. Mir erschließt sich, wie anderen auch, nicht wirklich der Sinn hieraus.

Unter XP gab es noch Lösungen in Form eines Installationsparameters für das Adminpak oder eines Regfiles hierfür (s. nachfolgend), aber unter Windows 7 Pustekuchen. Stellt sich Microsoft das unter Sicherheit vor ? Logonrechte auf einen Server vergeben, nur um den Reiter "Einwahlrechte" sehen und nutzen zu können ?
Bekloppt !

Für Windows XP hingegen gab es noch Lösungen - wie folgt:

1. Installationsparameter für das Adminpak: "msiexec /i adminpak.msi ADDLOCAL=FeRRASConsole /qb"
2. Erstellen eines Regfiles
a) Neues Dokument mit dem Namen dialin.reg erstellen
b) Folgendes hineinkopieren:

QUOTE:
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\RasDialin.UserAdminExt]
@=""

[HKEY_CLASSES_ROOT\RasDialin.UserAdminExt\CLSID]
@="{B52C1E50-1DD2-11D1-BC43-00C04FC31FD3}"

[HKEY_CLASSES_ROOT\RasDialin.UserAdminExt.1]
@=""

[HKEY_CLASSES_ROOT\RasDialin.UserAdminExt.1\CLSID]
@="{B52C1E50-1DD2-11D1-BC43-00C04FC31FD3}"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MMC\NodeTypes{19195a5b-6da0-11d0-afd3-00c04fd930c9}\Extensions\NameSpace]
"{B52C1E50-1DD2-11D1-BC43-00C04FC31FD3}"="RAS Dialin - User Node Extension"


c) Im Ausführen-Dialog folgendes eingeben: regedit /s dialin.reg
d) DOS-Box aufrufen (CMD) und folgendes eingeben:

QUOTE:
cd /d %SystemRoot%\System32
copy \\ServerName\Admin$\System32\mprsnap.dll *.*
copy \\ServerName\Admin$\System32\rasuser.dll *.*
copy \\ServerName\Admin$\System32\rtrfiltr.dll *.*
regsvr32 rasuser.dll


e) OK anklicken, um die Registrierung der Rasuer Library zu bestätigen.
Anschließend sollte der Reiter "Einwahlrechte" verfügbar sein

Windows-Profile mit Zusatz .v2

Wer sich wundert, dass er plötzlich neben den gewohnten Benutzerprofilverzeichnissen auf seinem Windows-Server solche mit dem Zusatz ".v2" findet, braucht sich keine Gedanken zu machen.
Es handelt sich hierbei um Profilverzeichnisse von Usern, die ursprünglich ein XP-Profil hatten und sich zwischenzeitlich an einer Windows 7 Maschine angemeldet haben.

Microsoft trennt in diesem Fall von sich aus beide Profile.

XP = %username%
W7 = %username%.v2


Damit sollte man eine Übersicht haben, die so ähnlich aussieht:

HMustermann
BLustig
AMusterfrau
HDampf
HDampf.v2
GMüller
B.Schmidt
B.Schmidt.v2
FMeier

usw.

UPDATE und Lösung: McAfee Update 5958 legt Windows lahm

Ok, wir haben das Problem soweit in Griff.
Betroffen waren tatsächlich Windows XP SP3 Rechner mit McAfee 8.7 und deren Svchost.exe.
Eine einfache Wiederherstellung der Datei über die Reparaturkonsole der Windows XP CD brachte die Systeme wieder an den Start.
Nachfolgend die Reparaturanleitung:

1. Windows XP CD einlegen und den Rechner von CD booten
2. In der ersten Eingabeaufforderung "R" für Reparaturkonsole drücken
3. Im Prompt die Windows-Installation (i.d.R. "1") auswählen und das Adminkennwort eingeben - sofern eins vergeben wurde.
4. Danach eingeben: cd D:\I386 (sofern D:\ der Laufwerksbuchstabe des DVD-Laufwerks ist)
5. Der Pfad sollte danach D:\I386 lauten. An dieser Stelle nun eingeben: Expand svchost.ex_ C:\windows\system32 (sofern C:\windows\... Laufwerksbuchstabe und Pfad zur Windows-Installation sind)
6. Die Frage mit "ja" bestätigen ob die bestehende Datei "svchost.exe" überschrieben werden soll.
7. Abschließend kommt man per "exit" (ohne die "") aus der Konsole und macht einen Reboot.

Nach dieser Aktion fährt das System wieder ordnungsgemäß hoch.
Danach sollte man direkt ein Update von McAfee durchführen. Es ist bereits das Update 5959 verfügbar, in dem das Problem offenbar bereits gefixt wurde.



** UPDATE **

Heute morgen erhielten wir von McAfee noch folgende Lösung, die wir aber noch (noch) nicht getestet haben:

QUOTE:

Restoring SVCHOST.EXE on computers affected by DAT 5958
1. Start your computer in Safe Mode (When starting press F8 and pick Safe Mode).
2. Open My Computer.
3. Double-Click the C:\ drive.
4. Double-click Program Files.
5. Double-click McAfee.
6. Double-click VirusScan.
7. Delete the DAT folder.
8. Press the CTRL, SHIFT, and ESC keys at the same time to open Task Manager.
9. Click File and select New Task (Run)...
10. Type CMD and press Enter.
11. In the command prompt window type:

copy %systemroot%\system32\dllcache\svchost.exe %systemroot%\system32\


12. Press Enter.
13. After the copy is completed restart the computer.
14. After the computer restarts, right-click the M icon and manually check for an update to get the new DAT files



Zudem bietet McAfee ein SuperDAT Remediation Tool an, mit dem sich das Problem beheben lassen soll:


QUOTE:

McAfee has developed a SuperDAT remediation Tool to restore the svchost.exe file on affected systems.

Q: What does the SuperDAT Remediation Tool Do?
A: The tool suppresses the driver causing the false positive by applying an Extra.dat file in c:\program files\commonfiles\mcafee\engine folder. It then restores the svchost.exe by looking first in %SYSTEM_DIR%\dllcache\svchost.exe, if not present it will attempt a restore from %WINDOWS%\servicepackfiles\i386\svchost.exe, if not present it will attempt a restore from quarantine. After the tool is run, the machine needs to be rebooted.

Recommended Recovery SuperDAT Procedure
1. From a machine that has Internet access, locate and download the Recovery SuperDAT at http://download.nai.com/products/mcafee-avert/tools/SDAT5958_EM.exe and save it to portable media.
2. Take the portable media to each affected machine and run the tool. If you are not able to run the tool on the affected machine, boot in safe mode
3. Execute the Recovery SuperDAT tool
4. Reboot in normal mode
5. Use the product update to update to 5959

For additional FAQs and information, go to https://kc.mcafee.com/corporate/index?elq_mid=2373&elq_cid=267942&page=content&id=KB68780 which will remain up to date.

XP - Keine Anmeldung möglich - Unzulässiger Zugriff auf Speicherbereich

An einem Rechner tritt das Problem auf, dass sich ein Domain-User nicht mehr anmelden können, während die Anmeldung des lokalen Admins problemlos funktioniert.
Bei der Anmeldung am Netzwerk (egal mit welchem User-Account) erscheint lediglich die Meldung:

QUOTE:
"Sie können aufgrund folgenden Fehlers nicht angemeldet werden: Unzulässiger Zugriff auf den Speicherbereich. [...]"


Klickt man auf "OK" und versucht erneut sich anzumelden, erhält man folgende Meldung:

QUOTE:
"Sie konnten nicht angemeldet werden, da der Server, der die Authentifizierung durchführt, einen Fehler gemeldet hat. (0xC00000BB) [...]"


Nach diesen Meldungen kann sich auch der lokale Admin nicht mehr anmelden, was erst nach einem Neustart des Rechners wieder möglich ist.

Schaut man dann ins Eventlog, findet man u.a. folgende Fehlermeldungen:

1 Unter "System": "Das Sicherheitspaket Kerberos verursachte eine Ausnahme und wurde deaktiviert. Daten: Ausnahmeinformationen."
2. Unter "Anwendungen": Event-ID 1053 Userenv "Der Benutzer oder der Gruppenname kann nicht ermittelt werden (Der Authentifizierungsdienst ist unbekannt). Die Verarbeitung der Gruppenrichtlinie wurde abgebrochen.
3. Unter "Anwendungen": Event-ID 1000 UserInit "Folgendes Skript konnte nicht ausgeführt werden: Start.bat. Das System kann die angegebene Datei nicht finden." (Anm. Die "Start.bat" wird bei der Anmeldung eins Domain-Users ausgeführt und beinhaltet diverse Informationen wie Laufwerksmappings, etc.)
4. Unter "Anwendungen": Event-ID 15 AutoEnrollment "Die automatische Zertifikatsregistrierung für "lokaler Computer" konnte keine Verbindung zum Active Directory (0x8007052b) herstellen. Das Kennwort kann nicht aktualisiert werden. Der Wert, der für das aktuelle Kennwort angegeben wurde, ist falsch. Die Registrierung wird nicht durchgeführt."

Wo könnte hier das Problem liegen ?
Eine Authentifizierung gegen das AD funktioniert, wenn man sich z.B. als lokaler Administrator anmeldet und einen Serverpfad unter einem anderen Benutzernamen als Laufwerk mappt.


In meinem Fall schien einer der RAM-Bausteine das Problem verursacht zu haben !

Ich steckte die Platte aus dem Rechner in ein identisches System. Resultat: Anmeldung erfolgreich !
Anschließend steckte ich die Platte zurück in den "fehlerhaften" Rechner und tauschte die RAM-Bausteine aus diesem gegen die des anderen. Resultat: Anmeldung erfolgreich.
Dann meldete ich mich an dem anderen Rechner an, der jetzt mit den RAMs des "fehlerhaften" PCs bestückt ist und siehe da: Anmeldung auch möglich !

Das heißt: auf beiden Rechnern ist jetzt die Anmeldung möglich !


Damit könnte ein Wackelkontakt oder nicht richtig sitzender Speicherbaustein die Lösung des Problems gewesen sein.

Muss nicht, kann aber. ;-)

Page 1 of 3, totaling 14 entries