Erstellt von Andyt am 1. Februar 2012
- Betrifft: Produktaktivierung mittels Key Management Service
- System: Microsoft Windows Vista, Windows 7, Server 2008 x64 und Windows Server 2008 R2 x64
- Problem: Wie erreiche ich eine automatische Produktaktivierung über einen Key Management Service ohne dass der Computer bzw. Server Mitglied einer Domäne ist?
Hintergrund
Für gewöhnlich wird bei einer Volumenlizenzierung von Microsoft Betriebssystemen ein Key Management Service (=KMS) verwendet. Ab 25 Clients bzw. 5 Server fragen die KMS Clients beim KMS Host nach einer Aktivierung. Bei erfolgreicher Aktivierung sind die Geräte aktiviert und müssen erst wieder nach einer bestimmten Zeit aktiviert werden.
Der Vorteil dieser Aktivierung ist bei automatischen Installationen gegeben. Man spart sich die Eingabe des Produktschlüssels bei jeder Installation und im Nachhinein die Aktivierung. Die Computer bzw. Server sind meist Mitglied einer Domäne der jeweiligen Firma. Daher funktioniert die Suche nach dem KMS Host automatisch und ohne weiterer administrativer Tätigkeit. Lediglich der KMS Host muss einmal eingerichtet und bei Microsoft über eine Internetverbindung freigeschaltet werden.
Ab Microsoft Office 2010 gibt es auch erstmals für Anwendungen diese Art der Aktivierung.
Bei Microsoft Windows Computern, die sich in einer Arbeitsgruppe befinden, ist für gewöhnlich die Nutzung als KMS Client nicht vorgesehen. Manchmal ist dies aber z.B. für Testzwecke in Entwicklungsumgebungen notwendig. Eine automatische Aktivierung passiert aber nicht. Bei der manuellen Aktivierung wird nach einer Lizenznummer gefragt.
Behebung
In Wirklichkeit muss ein Computer nicht Mitglied einer Domäne sein. Es wird aber dann einfach der KMS Host nicht gefunden. Wenn man bei diesen Computern, die sich in einer Arbeitsgruppe befinden, den KMS Host manuell einträgt, dann funktioniert auch die automatische Aktivierung.
Dazu gibt es vier Möglichkeiten. Der jeweilge Befehlt muss im Command-Prompt (= “cmd”) mit Administratorenrechte ausgeführt werden.
Variante 1, KMS Host mit kompletter Domänenbezeichnung (=FQDN) angegeben:
| cscript \windows\system32\slmgr.vbs /skms *KMS_FQDN*:*Port* |
Variante 2, KMS Host mit IPv4 Adresse angegeben:
| cscript \windows\system32\slmgr.vbs /skms *IPv4Addresse*:*Port* |
Variante 3, KMS Host mit IPv6 Adresse angegeben:
| cscript \windows\system32\slmgr.vbs /skms *IPv6Addresse*:*Port* |
Variante 4, KMS Host mit NETBIOS Namen angegeben:
| cscript \windows\system32\slmgr.vbs /skms *NetbiosName*:*Port* |
*Port* ist meistens 1688. Ein Beispiel: >>>cscript \windows\system32\slmgr.vbs /skms 192.168.0.1:1688<<<
weitere relevante Beiträge...
Abgelegt unter Tutorial, Windows | Keine Kommentare »
Erstellt von Andyt am 7. Dezember 2011
- Betrifft: Windows Powershell
- System: Microsoft Windows XP oder Windows Server 2003 mit installiertem Powershell oder Windows Vista, Windows 7, Server 2008 x64, Windows Server 2008 R2 x64
- Problem: Wie erhalte ich eine komplette Liste aller Einträge aus “Software” bzw. “Programme und Funktionen”?
Hintergrund
Windows Powershell ist eine moderne Alternative für die Kommandozeile (“cmd”) und beinhaltet viele Vorteile. Erst hier kann man komplexe Skripte erstellen und objektorientiert verarbeiten lassen.
Durchführung
Variante 1: Ausgabe direkt in Powershell als Tabelle
| Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\* | sort -Property DisplayName | Format-Table DisplayName, Publisher, DisplayVersion |
Variante 2: Ausgabe in eine Tabelle als CSV-Datei*
| Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\* | sort -Property DisplayName | select-object DisplayName, Publisher, DisplayVersion | Export-Csv -path installierte_programme.csv -UseCulture |
Variante 3: Ausgabe als Liste in eine TXT-Datei*
| Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\* | sort -Property DisplayName | format-list DisplayName, Publisher, DisplayVersion | out-File installierte_software.txt |
* = die jeweilige Datei wird in den aktuellen Pfad geschrieben. Also der zwischen “PS” und “>” angegeben wird.
weitere relevante Beiträge...
Abgelegt unter Tutorial, Windows | Keine Kommentare »
Erstellt von Andyt am 5. Dezember 2011
- Betrifft: Windows Deployment Services und Routing & RAS Services
- System: Microsoft Windows Server 2008 x64, Windows Server 2008 R2 x64
- Problem: nach der Installation von Routing & RAS auf einem Server mit installierten Windows-Bereitstellungsdienste (Windows Deployment Services) erhält man regelmäßig Fehlermeldungen in der Ereignisanzeige. Es ist kein DHCP Server installiert.
Hintergrund
Seit kurzem oder seit langem wird ein Windows Server mit den Windows-Bereitstellungsdienste verwendet. Nun ist ein neuer Dienst für VPN-Zugriff hinzugekommen: Routing & RAS Services.
Direkt nach der Installation erhält man regelmäßig die folgende Fehlermeldung:
| Deutsch |
Englisch |
|
Log File: Application
Type: Fehler
Source: WDSServer
Category: WDSServer
Event: 772
User: N/A
Computer: *Servername*
Message: Fehler beim Erstellen des UDP-Endpunkts für den Anbieter "WDSPXE" an Schnittstelle "*IP-Adresse*:67". Solche Fehler können auftreten, wenn die Netzwerkschnittstelle deaktiviert oder geändert wurde, oder wenn der Port bereits von einer anderen Anwendung belegt wird. Der Anbieter kann an dieser Schnittstelle keine Anforderungen empfangen.
Fehlerinformationen: 0×2740
|
Log File: Application
Type: Error
Source: WDSServer
Category: WDSServer
Event: 769
User: N/A
Computer: *server name*
An error occurred while trying to create the UDP endpoint for WDSPXE provider on interface *ip address*:67. This can happen if the network interface was disabled or changed, or some other application is already using the port. The provider will not be able to receive requests on this interface.
Error Information: 0×2740 |
*IP-Adresse* bzw. *ip address* verwendet der RAS Dienst zur Kommunikation mit den VPN-Clients.
Das Ganze hat mit der Tatsache zu tun, dass WDS und DHCP nicht gemeinsam laufen dürfen. Der WDS lauscht so wie der DHCP Dienst auf gemeinsam verwendete Ports und das geht mal gar nicht.
Nun ist zwar keine DHCP Server Rolle installiert, aber womöglich für die VPN-Clients konfiguriert. Also das diese die IP-Adresse automatisch von einem anderen DHCP Server im Netzwerk erhalten. Und aus diesem Grund wird zumindest auf der RAS Server IP-Adresse wie bei einem echten DHCP Server ebenso gelauscht und an den richtigen DHCP Server weitergeleitet. Daher auch die Fehlermeldung mit dieser IP-Adresse.
Behebung
Für die Behebung gibt es zwei Varianten. Je nachdem ob man über die Verwaltungskonsole für die Windows-Bereitstellungsdienste ein Fehler erhält oder nicht. Der einfachste Schritt ist mithilfe der Verwaltungskonsole die Eigenschaften (im Kontextmenü zu finden) aufzurufen. Danach in das Register "DHCP" wechseln und die Option "Port 67 nicht abhören" aktivieren.
Sofern man beide Optionen aktiviert erhält man die Fehlermeldung: "Der Microsoft DHCP-Dienst wird auf dem Server nicht ausgeführt."
Eigentlich ganz klar, denn der DHCP-Server Dienst wird ja nicht ausgeführt. Somit ist die zweite Option "DHCP-Option ’60′ konfigurieren um anzugeben, dass es sich bei diesem Server auch um einen PXE-Server handelt" NICHT aktivieren.
Alternativ kann man die Option via Registrierungseditor angeben. Aber ich gebe bewusst eine weniger detaillierte Anleitung. Man sollte wissen was "Regedit" und die nachfolgenden Werte bedeuten, bevor man etwas ändert.
Pfad: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE
Eintrag: UseDHCPPorts = 0
weitere relevante Beiträge...
Abgelegt unter Tutorial, Windows | Keine Kommentare »
Erstellt von Andyt am 30. September 2011
- Betrifft: Remote-Management bzw. Fernverwaltung bei Hyper-V (R2)
- System: Microsoft Windows Server 2008 und Windows Server 2008 R2 mit jeweils aktivierter Hyper-V Rolle
- Problem: Nach dem einrichten der Hyper-V Rolle möchte man den Server über eine Remoteverbindung mittels Hyper-V-Manager Konsole von einem Windows Vista bzw. Windows 7 steuern
Hintergrund
Die Hyper-V Rolle ist eine Virtualisierungsplattform auf Windows Server 2008 und Windows Server 2008 R2. Es gibt ebenso eine kostenfreie Version, die nur unter Hyper-V Server erhältlich ist.
Nun gibt es für Windows Vista bzw. Windows 7 die Remote Server Administration Tools (= RSAT):
Dort ist nach der Installation die Hyper-V-Manager Konsole verfügbar, mit der man sich praktisch auf den Server über das Netzwerk verbinden könnte. Leider erhält man aber nur eine Fehlermeldung:
| Sprache |
Deutsch |
Englisch |
| Fehlermeldung |
Sie besitzen nicht die erforderliche Berechtigung für diese Aufgabe. Wenden Sie sich an den Administrator der Authorisierungsrichtlinie für Computer “XYZ”. |
You do not have the requested permission to complete this task. Contact the administrator of the authorization policy for the computer “XYZ” |
“XYZ” steht für den Hyper-V Server bzw. Windows Server mit aktivierter Hyper-V Rolle.
In der Hyper-V-Manager Konsole am Server selbst wird keine Möglichkeit für die Benutzerverwaltung gefunden. Ebenso gibt es keine angelegte Benutzergruppe, bei der man ansetzen könnte.
Behebung
Es gibt viele manuelle Schritte um zum Ziel zu gelangen. Dies wird bei Microsoft Technet beschrieben. Einfacher und viel effizienter ist ein gefundenes Skript, das von John Howard (Senior Program Manager im Hyper-V Team bei Microsoft) erstellt wurde.
- Man benötigt das Hyper-V Remote Management Configuration Utility von der MSDNCodeGallery: http://code.msdn.microsoft.com/HVRemote
- Diese notwendige Datei hvremote.wsf gehört auf den Hyper-V Server bzw. Windows Server mit aktivierter Hyper-V Rolle kopiert.
- Der Command-Prompt muss mit Administratorenrechte gestartet werden.
- entweder mit “Windows-Taste + R” und danach im Ausführen-Fenster “cmd” eingeben.
- oder mittels Windows-Suche nach dem Programm “cmd” suchen, Rechtsklick mit der Maus und “Als Administrator starten” auswählen.
- Es wird der Command-Prompt oder auch Konsolenfenster geöffnet. Dort den richtigen Pfad mit der hvremote.wsf Datei aufsuchen.
- In meinem Fall reicht nun die Eingabe eines einzigen Befehles, da alle Systeme sich in einer Domäne befinden.
| cscript hvremote.wsf /add:*Domäne*\*Benutzer* |
z.B. “cscript hvremote.wsf /add:BS\Test”
- Der Hyper-V Server bzw. Windows Server mit aktivierter Hyper-V Rolle muss nun neu gestartet werden.
Am Windows Client musste ich keine Anpassungen vornehmen. Wenn es noch nicht klappen sollte, dann einfach die hvremote.wsf Datei auf den jeweiligen Verwaltungscomputer kopieren und im Command-Prompt im richtigen Verzeichnis den Befehl:
| cscript hvremote.wsf /mmc:enable |
ausführen.
Natürlich wird die Konfiguration bei einer Arbeitsgruppe ebenfalls unterstützt. In diesem Fall sind ein paar weitere Schritte notwendig. Leider muss dabei ein eher unschöner Befehl ausgeführt werden: anonyme Anmeldung für DCOM Zugriff erlauben. Meine Empfehlung deshalb: Wenn es möglich ist, immer alle Geräte in die Domäne bringen.
Ich erspare mir hier eine weitere Anleitung und verweise nur auf die 10-Sekunden Schritte für Hyper-V Remote Management. Alternativ habe ich einen durchaus älteren, aber noch gültigen Beitrag Windows 7/Server 2008 R2: Hyper-V Remote Management gefunden. Bei beiden Artikeln wird die Situation, dass sich das System in einer Arbeitsgruppe befinden ausführlich behandelt.
weitere relevante Beiträge...
Abgelegt unter Tutorial, Windows | Keine Kommentare »
Erstellt von Andyt am 12. Juni 2011
- Betrifft: 8+3 Dateinamenerstellung deaktivieren auf NTFS Partitionen
- System: Microsoft Windows NT5.0 und höher
- Problem: Bei NTFS Dateiformat sind Dateinamen mit mehr als 8 Zeichen im Präfix und 3 Zeichen im Suffix möglich. Trotzdem wird zusätzlich für jede Datei ein 8+3 Dateiname erstellt. Ist dies noch notwendig?
Hintergrund
Eingeführt wurde die 8+3 Bezeichnung zu Zeiten von DOS. Zu Beginn hatte jede Datei maximal 8 Zeichen für den Namen und 3 für die Endung zur Verfügung. Bei der weiteren Entwicklung wurde eine längere Bezeichnung darüber gestülpt. Damit meine ich, als Benutzer sah man Dateien mit mehr als 8 Zeichen, jedoch das System verwendete trotzdem den 8+3 Dateinamen. Während der weiteren Veränderung wurden mehr und mehr Bestandteile vom System kompatibel mit der längeren Bezeichnung gemacht. Ebenso begannen Anwendungen oder Spiele diese längere Bezeichnung zu verwenden.
Trotzdem ist nach wie vor bis zu Windows 7 oder Windows Server 2008 R2 die doppelte Dateinamenerstellung aktiv und das ebenso beim NTFS Partitionen, die im Prinzip Zeichen und Pfade weit über 255 unterstützen. Beim FAT oder FAT32 Dateiformat ist nach wie vor allein schon vom Grundsystem die 8+3 Bezeichnung in gewisser Weise notwendig, jedoch bei NTFS ist bereits mit der ersten Version die längere Bezeichnungen integriert worden. Der Grund trotzdem die 8+3 Dateinamen zu erstellen liegt an der abwärtskompatibel zu älteren Programmen und dies genauso für Windows 7 und besonders für Server mit Windows Server 2008 R2.
Aber für stark belastete Dateiserver bzw. Partitionen auf den keine Programme laufen und nur als Datenspeicher verwendet werden ist es empfehlenswert diese 8+3 Dateinamenerstellung zu deaktivieren. Für Systempartitionen empfehle ich selbst unter aktuellen Systemen auch unter NTFS Partitionen davon abzusehen.
Behebung
- Der Command-Prompt muss mit Administratorenrechte gestartet werden.
- mit “Windows-Taste + R” und danach im Ausführen-Fenster “cmd” eingeben.
- mittels Windows-Suche nach dem Programm “cmd” suchen, Rechtsklick mit der Maus und “Als Administrator starten” auswählen.
- Es wird der Command-Prompt oder auch Konsolenfenster geöffnet.
- Ab Windows XP bzw. Windows Server 2003 wird ein Befehl verwendet.
| ab Windows NT 6.1 |
fsutil 8dot3name set X |
nur für NTFS Partitionen |
| ab Windows NT 5.0 |
fsutil behavior set disable8dot3 Y |
für FAT und NTFS Partitionen |
X kann 0 bis 3 sein.
| 0 |
Aktiviert die Erstellung von 8+3 Dateinamen auf allen Partitionen im System. |
| 1 |
Deaktiviert die Erstellung von 8+3 Dateinamen auf allen Partitionen im System. |
| 2 |
Legt die Einstellung für die Erstellung von 8+3 Dateinamen für jede Partition einzeln fest. Hier muss ein Laufwerksbuchstabe zwischen set und der Zahl X mitangegeben werden. |
| 3 |
Deaktiviert die Erstellung von 8+3 Dateinamen auf allen Partitionen mit Ausnahme der Systempartition. |
Y kann 0 bis 1 sein.
| 0 |
Aktiviert die Erstellung von 8+3 Dateinamen auf allen Partitionen im System. |
| 1 |
Deaktiviert die Erstellung von 8+3 Dateinamen auf allen Partitionen im System. |
Nachfolgend einige Beispiele
| fsutil 8dot3name set 1 |
Deaktiviert die Erstellung auf allen Partitionen. |
| fsutil 8dot3name set C: 1 |
Deaktiviert die Erstellung nur auf Laufwerk C:\ |
| fsutil 8dot3name set 3 |
Deaktiviert die Erstellung auf allen Partitionen bis auf die Systempartition (meistens C:\). |
- Dieser Vorgang wird ab Windows NT6.0 umgehend wirksam (kein Neustart erforderlich). Das heißt nur für Windows XP und Windows Server 2003 ist ein Neustart notwendig.
Nachtrag
Mit folgendem Befehl kann der aktuelle Status ausgelesen werden:
Für Betriebssysteme vor Windows NT6.1 kann ebenso nur für NTFS Partitionen die 8+3 Dateinamenerstellung deaktiviert werden. Dazu muss die Registrierung bearbeitet werden: “regedit”.
| NtfsDisable8dot3NameCreation |
unter
| HKLM\SYSTEM\CurrentControlSet\Control\FileSystem |
als DWORD mit “X” (siehe oben) anlegen.
weitere relevante Beiträge...
Abgelegt unter Tutorial, Windows | 2 Kommentare »
Erstellt von Andyt am 18. April 2011
- Betrifft: Windows Virtual PC
- System: Microsoft Windows 7 mit Servicepack 1
- Problem: Beim Aufruf von Virtual PC bzw. beim Erstellen eines neuen virtuellen Computers erhält man nach etwas Wartezeit nur ein Fenster mit der Meldung "Überprüfen Sie, ob Windows Virtual PC installiert und der Virtual PC-Hostprozess ausgeführt wird. Überprüfen Sie die Systemereignisanzeige auf weitere Details. Fehlercode = 0×80080005." Nach dem Schließen des Fensters startet sich kein virtueller Computer.
Hintergrund
Es wurde bei Microsoft Windows 7 der Virtual PC installiert und anschließend das Servicepack 1 eingespielt. Das Servicepack wurde ordnungsgemäß installiert und ebenso Virtual PC funktioniert weiterhin ohne Probleme. Es hat durch das Servicepack 1 jedoch eine Aktualisierung für Virtual PC gegeben. Nach dem Tag X ist auf einmal die Fehlermeldung erschienen.
Einen Dienst mit der Bezeichnung "Virtual PC-Hostprozess" gibt es so nicht. Deshalb braucht man unter den Diensten nicht nachsehen. Der Hinweis auf die Ereignisanzeige liefert keine weitere nützliche Meldung, außer das etwas nicht starten kann. Nachfolgend noch eine Zusammenfassung:
| Sprache |
Deutsch |
Englisch |
| Hinweis |
Überprüfen Sie, ob Windows Virtual PC installiert und der Virtual PC-Hostprozess ausgeführt wird. Überprüfen Sie die Systemereignisanzeige auf weitere Details. Fehlercode = 0×80080005." |
Windows Virtual PC – Please ensure that Windows Virtual PC is installed and Virtual PC Host Process is running. Check the System event log for more details. Error code = 0×80080005 |
| Ereignisanzeige |
Der Server "{9A1774B7-8251-4468-A214-61DCAED9AC2F}" konnte innerhalb des angegebenen Zeitabschnitts mit DCOM nicht registriert werden.
|
The server {9A1774B7-8251-4468-A214-61DCAED9AC2F} did not register with DCOM within the required timeout. |
Beim Blick in den Geräte-Manager findet man zwei fehlerhafte Geräte (mit gelben Rufzeichen): Virtual PC-Hostbustreiber und USB-Virtualisierungsconnectortreiber.
In den Eigenschaften dieser Geräte wird angezeigt, dass ein Problem mit den digitalen Zertifikaten der Treiber vorzufinden ist. Damit haben wir den eigentlichen Grund gefunden. Der DCOM Eintrag {9A1774B7-8251-4468-A214-61DCAED9AC2F} ist nämlich exakt der Virtual PC-Hostbustreiber.
Eine Neuinstallation des Treiber hilft nicht. Genauso ein deaktivieren und aktivieren des Treibers. Eine reine Neuinstallation über die Windows Funktionen scheitert ebenso (gemeint ist deaktivieren und aktivieren).
Behebung
An sich ganz leicht. Man nimmt das richtig aktualisierte Virtual PC Refresh, das speziell für Windows 7 SP1 angepasst wurde. Was man nicht vergessen darf: Virtual PC muss zwei Mal deinstalliert werden. Einmal über die Windows-Funktionen und einmal über "Installierte Updates anzeigen". Ein darüber installieren der neuen Version hilft leider nicht. Somit nachfolgend alle Schritte:
1.) "Windows Virtual PC" über die "Windows-Funktionen aktivieren oder deaktivieren" unter "Programme und Funktionen" deaktivieren.
2.) Es ist ein Neustart erforderlich
3.) Nun "Windows Virtual PC (KB958559)" über die "Installierte Updates anzeigen" deinstallieren
4.) Es ist ein Neustart erforderlich
5.) Über das Microsoft Download Center das Windows Virtual PC Paket je nach eigenem System - Windows6.1-KB958559-x64-RefreshPkg.msu oder Windows6.1-KB958559-x86-RefreshPkg.msu – mit der Versionsnummer 6.1.7600.16393 herunterladen.
6.) Mittels Doppelklick auf die heruntergeladene Datei installieren.
7.) Es ist ein Neustart erforderlich
8.) Virtual PC wird automatisch aktiviert und steht nach dem Neustart ohne weiterer Installation zur Verfügung. Die bereits eingerichteten virtuellen Computer sollten ohne Verlust sofort zur Verfügung stehen und nun wieder starten.
weitere relevante Beiträge...
Abgelegt unter Tutorial, Windows | 2 Kommentare »
