Hannibal

Oh ha, Danke für die schnelle Antwort. Sollte ich hinbekommen, melde mich wieder!

Hallo Zusammen! Für ein Projekt wurde mir ein ehemals über "Key Management Service" lizensierter "Windows Server 2008 R2 Standard" zur Verfügung gestellt. Diesen müsste ich nun wieder ohne "KMS" lizensiert betreiben, womit wir beim Thema "Microsoft Lizensierung" sind und das ist nicht gerade meine Stärke. :P Über einen Tip wär ich dankbar.

Oki dann danke ich euch für die schnelle Hilfe, ich experimentier mal bischen rum. ;)

Das hatte ich auch gefunden, aber so richtig kapiert hab ich es nicht, was vermutlich an meinen Einsteigerkenntnissen von vbs liegt. Es wird die GPO mit der OU verknüpft oder die Verknüofung wird auf- gehoben? Wobei ich das aufheben der Verknüpfung in dem Quelltext nicht erkenne. MS hat doch fast für jeden **** ein schlaues Tool, aber wohl nicht zum GPO an-/aus knispen. :P

Holá :) Ich suche ein Script womit ich GPOs de-/ativieren kann. Hab da kein Shell Tool gefunden oder vielleicht auch falsch gesucht. Habt ihr ne Idee für mich?

Ah Danke :D Hab mir schon selber Gedanken gemacht und angefangen an einer Batch zu basteln die mir das sechste Token quasi durch 1024 teilt und dann einfach hinten wieder dranghängt. Aber mit Deinem tip gehts leichter... sollte mich wohl doch mal mit vbs und am besten powershell beschäftigen. Besten Dank nochmals! :p

Hallo zusammen. ;) Fals der Beitrag nicht hier reinpassen sollte, bitte entsprechend verschieben. ________ Kurzform: - Netzlaufwerk der Firma ist vollgelaufen - es soll eine Dateianalyse für alle Abteilungsverzeichnisse erstellt werden - gewünschte Informationen: Dateipfad, Dateiname, Datum der letzten Änderung und Dateigröße - Übersicht der Verzeichnisse in eine .xls zwecks weiterer Auswertung ________ Langform: Die Firma hat es mal wieder geschafft ihr Netzlaufwerk vollzuballern. Es soll den Nutzer bewust gemacht werden, welche Dateien auf dem Netzlaufwerk unnötig abgespeichert wurden und welche man zB auf eine DvD brennen kann zb die Fotos der letzten Firmenparty. Das passende vbs Scpit zur Dateianalyse im gewünschten Format hab ich im MS Script Repository gefunden und bisher hab ich nichts besseres gefunden. Ich habe von allen Abteilungsverzeichnissen eine Reportdatei, im Format .txt, erstellt. Mir geht es nun um die weitere Verarbeitung/Aufbereitung der Reportdateien. __ Excel kann nur 65636 Zeilen pro Tabelle verarbeiten/darstellen, die Firma hat aber Abteilungsverzeichnisse mit mehr als 150.000 Dateien. In Access stellte sich der Import vorrest als gelungen da. Ich konnte zb die Spalte "Dateigröße" absteigend sortieren und mit tausender-Punkten versehen. Jedoch gibt es in den Abteilungsverzeichnissen Dateien die größer als 2GB sind. In den Reportdateien liegt die Dateigröße in Byte vor zb 4632234467. Da man beim ".txt Import" in Access maximal "long Integer" (-2,1/+2,1*10^12) als Datentyp einrichten kann, verliere ich alle Informationen zu den Dateien größer 2GB und auf genau die kommt es an! Ich überlege nun die Erstellung der Reportdatei anzupassen, sodass die Dateigröße geich in Kilobyte vorliegt, womit Access wieder zurecht kommt beim Import. Leider bin ich aber nicht so vbs versiert um sowas in den Quell- text einzubauen. :( Eventuell gibt es eine Möglichkeit die .txt umzubauen das Access eine neue Tabelle erstellt und das auch noch mit float/dezimal Datentyp für die Dateigröße? Danke im vorraus. ;)

Ja doch... das hat schon der der Schreiberling vor dir kundgetan und nun ist auch mal gut. :p Da ich den VPlayer eh nicht nutzen wollte, sondern den XPMode hab ichs es wieder deinstalliert. Es ging ja nur drum ob andere V-Software läuft...

Ist doch installiert... siehe erster Thread, erst Satz. :suspect: Richtig und in irgendeiner CT stand sowas ähnliches geschrieben wie hier Auszug: "Microsoft wird Windows Virtual PC und Windows XP Mode allen Windows-7-Käufern kostenfrei zur Verfügung stellen, die Windows 7 Professional, Windows 7 Ultimate oder Windows 7 Enterprise erwerben. Diese Anwender erhalten damit gratis zusätzlich zu Windows 7 auch eine Lizenz für Windows XP." Sollte ich da was falsch verstanden haben, klärt mich auf. :p VMPlayer+WinXP installiert und läuft tadelos, auch mit Deamon Tools. Eben dacht ich es liegt an Deamon Tools. Hatte das deaktiviert, aber vorher noch "Virtual PC 2007" installiert. Da lief VPC+XP Mode und habs erstmal durchinstalliert. Habs dann beendet und "Deamon Tools" gestartet, jedoch lies sich VPC/XPMode wieder starten. Hab dann einen Reboot gemacht und jetzt mit laufenden Deamon Tools, lässt sich VPC/XPMode nicht starten. Es muss also was anderes sein, was VPC/XPMode am starten gehindert hat. /EDIT Verdammich... ich bekomms nicht mehr reproduziert. VPC kam mit dem "Virtual PC 2007" nicht klar, musste letzteres deinstallieren.

Nach der Installation von "Windows6.1-KB958559-x64.msu" (VPC) liegt eine Key.txt im Verzeichnis, die wollt ich nutzen. Anderer Ansatz: Mit "Disk2VHD" hab ich mein altes WXP nun als .vhd vorliegen. Ziehe mir gerade den "Virtual PC 2007" und werd das mal antesten. :p Hab aber nach wie vor nichts gefunden zur oben genannten Fehlermeldung. :suspect:

Hab nun den VMWare Player installiert und könnten nun ein XP installieren. :cool:

Hiho =) Hab vorhin Virtual PC + XP Mode installiert und bekomme die Fehlermeldung: "Windows Virtaul PC kann nicht gestartet werden, während weitere Virtualisierungssoftware ausgeführt wird. Schließen Sie die andere Virtualisierungss. und wiederholen Sie den Vorgang." Hab hier bzw im Netz nichts passendes gefunden bzw hab ich paar Beiträge gefunden, wo aber nur einer durch Neuinstallation von VPC erfolg hatte. Das hab ich natürlich auch schon ausprobiert, aber ohne Erfolg. OS: Win7x64ultimate CPU: AMD x4 3GHz ... und ja, im Bios ist die Option "Virtualisierung" eingeschaltet. :cool: Weis im moment nicht so recht weiter, vielleicht hat ja einer von euch eine zündende Idee. :p Danke im vorraus

Hallo Miteinander :) Ich bräuchte mal Hilfe bei einem SMS Problem. Letztendlich stellt es sich für mich als WMI Problem da. Hier mal paar Logfile-Auszüge: Ereignistyp: Warnung Ereignisquelle: Ftdisk Ereigniskategorie: Datenträger Ereigniskennung: 57 Datum: 30.12.2009 Zeit: 15:36:58 Benutzer: Nicht zutreffend Computer: SMSSRV01 Beschreibung: Die Daten konnten nicht in das Transaktionsprotokoll verschoben werden. Möglicherweise sind die Daten beschädigt. Ereignistyp: Fehler Ereignisquelle: Application Popup Ereigniskategorie: Keine Ereigniskennung: 333 Datum: 30.12.2009 Zeit: 15:37:31 Benutzer: Nicht zutreffend Computer: SMSSRV01 Beschreibung: Ein E/A-Vorgang, der durch die Registrierung ausgelöst wurde, ist fehlgeschlagen. Dieser Fehler ist nicht korrigierbar. Die Registrierung konnte eine der Dateien mit dem Systemabbild der Registrierung nicht einlesen oder schreiben. Der Server hat sich schließlich an den Festplattenproblemen aufgehangen. Am 04.01., erste Arbeitstag im neun Jahr, ist uns dann aufgefallen das er nicht reagiert, womit wir ihn neugestartet haben. Als erstes warf ich ein chkdsk an, was auch erfolgreich durchlief. Nachdem Neustart fand ich jedoch "ntfs" und "dcom" Fehlermeldungen im System-Log: Ereignistyp: Fehler Ereignisquelle: Ntfs Ereigniskategorie: Datenträger Ereigniskennung: 55 Datum: 04.01.2010 Zeit: 09:40:01 Benutzer: Nicht zutreffend Computer: SMSSRV01 Beschreibung: Die Dateisystemstruktur auf dem Datenträger ist beschädigt und unbrauchbar. Führen Sie chkdsk auf Volume "System" aus. Ereignistyp: Fehler Ereignisquelle: DCOM Ereigniskategorie: Keine Ereigniskennung: 10016 Datum: 04.01.2010 Zeit: 09:40:01 Benutzer: SMSSRV01\IWAM_SMSSRV01 Computer: SMSSRV01 Beschreibung: Durch die Berechtigungseinstellungen (Anwendungsspezifisch) wird der SID (S-1-5-21-207662197-3625498708-3400172451-1004) für Benutzer SMSSRV01\IWAM_SMSSRV01 keine Start- berechtigung (Lokal) für die COM-Serveranwendung mit CLSID {1A9FFCE9-10C1-40BC-9815-B20C1DC2D156} gewährt. Diese Sicherheitsberechtigung kann mit dem Verwaltungsprogramm für Komponentendienste geändert werden. Um einen zeitlichen Zusammenhang zu erkennen hab ich mir noch die Logfiles vom SMS Server angeschaut, unteranderem die "LocationServices.log": Am 28.12.09 seh ich noch wie gewohnt die Einträge: - "Attempting to retrieve default management point from AD" - "Attempting to retrieve default management point from WINS" - "Attempting to retrieve NLB default management point from WINS" - "Retrieved Default Management Point through WINS: xxx.xxx.xxx.xxx" Ab dem 30.12.09, 3 bis 15 Uhr sind stündliche Einträge zu sehen: - Failed to query WMI Ab 30.12.09 ~16 Uhr bis der Server sich aufgehangen hatte: - Failed to open to WMI namespace '\\.\root\ccm' (800705aa) Am 04.01.10 wurde der Server neugestartet. Seit dem Zeitpunkt steht in der Logdatei "LocationServices.log": - Failed to send Location Request Message - Failed to create Location Request Message body - Failed to resolve IP address from WINS - Failed to retrieve MP for site code 'CON' - Unable to resolve proxy mp Diese Fehlermeldungen wiederholen sich seit dem. Ich hab nun selbst schon Rechere betrieben und bischen was zum reparieren vom WMI Ripositiory gefunden. Bevor ich nun aber hier am WMI Ripository anfange rumzubasteln, wollt ich mir lieber noch paar Meinungen einholen und nachfragen was ihr davon haltet und ob es jemanden gibt der eventuell bischen mehr Erfahrungen mit WMI und dessen Reparatur hat. :p Der SMS Server läuft nach wie vor. Nur können neuinstallierte Clients den SiteCode "CON" nicht erreichen und somit wird der erw. SMS Client nicht installiert den wir für Remoteaccess nutzen. Würd mich über paar Lösungsansätze freuen. :)

Hi =) Bisher hab ich von dem Reboot des Fileserverclusters, wo auch das Anmeldeskript liegt, abgesehen, da nur noch paar User die "15min Anmeldeproblematik" haben. Die restlichen User können sich ohne Probleme anmelden. Einen User hab ich mir gestern rausgesucht und bei seinem Client vor Ort ein "gpupdate" gemacht und anschließend mit "rsop.msc" und "gpreuslt" alles kontrolliert. Es sieht alles so aus wie bei einem Nachbar-Client wo es keine Anmeldeprobleme gibt. Aber leider ohne Erfolg. Hier im Board, sind Beiträge zur gleichen Problematik zufinden, die auf ein Problem mit der WMI-Schnittstelle hindeuten. An dem besagten Client hab ich im zweiten Schritt den WMI Dienste beendet und neugestartet, anschließend wieder ein Reboot, wieder ohne Erfolg. Ich hab an dem Client ein Testkonto zur Anmeldung ausprobiert, was ebenfals der 15min Anmelung unterlag. Nehme ich meinen Domänen Adminaccount bin ich innerhalb von wenigen Sekunden angemeldet. Ich sehe zb sofort nach der Passwortbestättigung das Anmeldeskript durchflitzen. Das verwirrende ist, das das Problem nicht bei allen Usern auftritt sondern nur bei 5~10 Usern, wir haben hier weit über hundert User die sich täglich anmelden. Einen User hab ich bisher gefunden der erst das Problem hatte, wobei es am Folgetag nicht mehr auftrat. An diesem Client ist nichts an "gpupdate" etc gelaufen. Das Problem löst sich quasi von selbst. Ich hab bei jedem User der sich bisher gemeldet hat, über die Registry nachgeschaut, welchen Logonserver er genutzt hat. (HKEY_User\<UserSID>\Volatile Environment" Schlüssel Logonserver) Bisher haben alle den SDC02 drinstehen. Nur wurde diese und der SDC01 bereits letzte Woch neugestartet. An dem SDC02 melden sich nach wie andere User ohne irgendein Problem an. Ich überlege ob ich testweise das Benutzerprofil an besagtem Client mal löschen um es neuanlegen zu lassen. Aber das sind mehr try&error Varianten... Habt ihr noch eine Idee? /EDIT Ein falsch konfigurierter DNS Server liegt auch nicht vor. Sonst hätten viel mehr User das Anmeldeproblem.

Guten morgen :P Erstmal Danke für Eure Hilfe! Der Reboot beider DCs hat nichts gebracht. Gestern Vormittag hatte ich eine zündende Idee. Ich hab mir noch das Loginscript angeschaut und was das so reibt um eine Ursache für die lahme Anmeldung zu finden. Im Skript selbst fand ich nichts, bin aber die restlichen Einstellungen der GPO durchgegangen und bei der Option hängengeblieben "Anmeldeskripte gleichzeitig ausführen". Diese hab ich kurzhand deaktiviert und einen User angerufen der die 15min Anmeldeproblematik hatte. Siehe da, die Anmeldung läuft durch. Habs noch mit paar anderen Problemfällen getestet, auch da erfolgreich. Die Option hatten wir eingeschaltet, um zu verhindern das der User schon auf Netzlaufwerke zu greift obwohl sie noch nicht gemapped sind. Es können nun Folgefehler durch das abschalten der Option entstehen, aber diese sind dann eher einfache Problemchen, bisher gibt es keine. Soweit so gut, jetzt gibt immerhin der UHD Ruhe. Jetzt kann ich weiter orschen wo das eigentliche Problem liegt. Das Loginscript verweist recht früh auf unseren Fileservercluster. Vielleicht schüttelt der sich bei paar Nutzeranmeldungen. Den werd ich aber erst heute Nachmittag oder Freitag wenn keine Nutzer mehr arbeiten, rebooten. Der Cluster liegt zb auch in der OU die ich versehentlich verschoben hatte. Auch wenn das verschieben nur für ~20sek war, könnte da ein Problem entstanden sein.

Hab auf meinen Client und beim Kollegen, sowie bei einem Normalouser das erweiterte "Userenv Logging" eingeschaltet mit: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon UserEnvDebugLevel, REG_DWORD, 10002 (logfile + verbose) Hab nun eine erfolgreiche Anmeldung von meinem und dem Client vom Kollegen vorliegen und die fehlgeschlagene vom Normalo-user. Als erster Unterschied ist mir aufgefallen das meine und die Anmeldung vom Kollega auf dem Logonserver, ich nennen ihn mal "sdc01", lief. Die Anmeldung vom Normalouser lief auf dem "sdc02". (sdc01 und sdc02 beispielhaft als Domäncontroller) Ich glaub der "sdc02" braucht mal ein reboot... Melde mich morgen wieder. :cool:

Hm ne das kam wohl falsch rüber. Die DC wurden nicht verschoben. Aber die OU die ich verschoben hatte, beinhaltet weitere OUs, zb wo Clients und Server einsortiert sind. Dadrunter liegt zB auch ein Fileserver für ein Laufwerksmapping was die Nutzer gemapped bekommen. Haben Sie nicht, steht auf automatisch. Die anderen Vorschläge werd ich mal testen. Danke

Hallo :) Letzten Freitag ist mir ein Fehler unterlaufen, der mir so noch nie passiert ist. :( Ich war im AD(Active Directory-Benutzer und -Computer) unterwegs und hab dabei versehentlich eine OU verschoben. In dieser OU waren die Clients, Server, Domänenkontroller etc enthalten. Mir ist der Fehlergleich aufgefallen, sodass ich die OU wieder an den ursprünglichen Ort zurückverschoben hatte. Anschließend hatte ich die Berechtigungen und Gruppenrichtlinien kontrolliert, dort hatte sich aber nichts verändert. Leider gibt es seit ab dem Zeitpunkt aber Probleme bei der Nutzeranmeldung, welche bis zu 15 Min dauert. Die ~15min Wartezeit entsteht aber erst ab dem Zeitpunkt wenn der Nutzer sein Benutzername/Passwort eingibt und bestättigt. D.h. das Computerkonto wird einwandfrei an der Domäne angemeldet. Um Anhaltspunkte zu finden hab ich mir von betroffenen Clients das Eventlog angeschaut, konnte aber keine Fehler ausmachen. Auch nach dem Wochenende gibt es immer noch paar Nutzer die Probleme mit der Anmeldung haben. Wenn diese ca 15 Min warten wird das Profil (Desktop, etc ...) geladen und sie können wie gewohnt arbeiten. Bisher vermutete ich das diese Nutzer ihren Client nicht ausgeschaltet haben über das Wochende. Aber auch nach einen Reboot dauerte die Anmeldung ca 15min. Ich suche nun nach einer Ursache/Grund wieso die Nutzeranmeldung ~15min drauert und wie ich den "Normalzustand" wiederherstellen kann. Habt ihr eine Idee? /EDIT Es gibt aber Nutzer die sich ohne Probleme heute anmelden konnten. Es betrifft also nicht alle Clients.

Quelle: http://www.mcseboard.de/windows-forum-ms-backoffice-31/auffordung-neustart-updates-111112.html Klasse Tip mit Nebeneffekt. Zumindest in meinem Fall bracht er die Lösung. ___ Für jeden User wurde auf meinem Terminalserver(win2k3r2) eine wuauclt.exe für 1~2sek gestartet und verschwand dann wieder. Das bekannte Neustartfenster, was aber eigentlich kein User sieht, das ist in der gpo deaktiviert dennoch wird die wuauclt.exe gestartet. Da dort aber bis zu ~35 User täglich arbeiten, stand der Server für die 1~2 Sekunden, was mehr als nervtötend war. Nun hab ich die Gruppen "Benutzer und Hauptbenutzer" auf beiden Dateien entfernt und siehe da keine "pumpende" 30fache "wuauclt.exe" mehr. Wollt das mal dokumentieren, vielleicht hilft das irgendwann irgendwem mal weiter :p

Hmpf, ich brauch ein VPN Client der auf Vista 64 Bit läuft. :shock: /EDIT Fragt mich nicht wieso 64 Bit, das hab ich meinen Chef auf gefragt...

Am 5.7. ~12 Uhr hab ich das SP2 für Win2k3 Server installiert. Ich dachte es wäre schon längst drauf, aber ich hab das Netzkonstrukt hier vor die Nase gesetzt bekommen. :p Nachdem ich das SP2 auf dem Lizenzserver installiert hatte blieben die Lizenzfehlermeldungen (s.o.) aus bis zum 6.7. ~20 Uhr. Ich dachte schon das wär die Lösung gewesen... :rolleyes:

Diese Maßnahme war die erste die ich schon vor Wochen eingeleitet hab, das bringt aber rein garnix.

Plage mich immer noch mit dem Problem rum. :suspect:

Der neue Client bekommt dann eine neue Lizenz, wenn du noch welcher in Reserve hast. Die temp. CAL wird bei der zweiten Anmeldung als permanente CAL ausgestellt.

Hatte soeben eine ähnliche Baustelle bearbeitet. Dabei war in einem Link von Wolke24 zulesen: Quelle Nach 52~89 Tagen sollte die Lizenz wieder im Lizenzpool in der Terminalserverlizensierung zu finden sein. Ich hoffe das bringt dich bischen weiter. :cool: