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...

Um den XP Mode richtig nutzen zu können, musst du Windows Virtual PC verwenden!

Ist doch installiert... siehe erster Thread, erst Satz. :suspect:

Wenn du ein virtuelles XP nutzen willst, brauchst du eine eigene Lizenz für dieses XP.

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

... läuft denn noch eine andere Virtualisierungssoftware, z.B. VMware?

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:

wie jetzt? Du hast die DCs aus der OU "Domain Controllers" in eine eigene OU verschoben und in der gleichen OU befinden sich auch die Clients?

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.

Prüfe als erstes ob die betroffenen Clients einen internen DNS-Server in ihren TCP/IP-Einstellungen eingetragen haben.

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.

Hallo,

damit User das Fenster nich zu sehen bekommen entferne auf dem Terminal-Server die NTFS Berechtigungen für nicht Administratoren auf die Dateien wuauclt.exe und wuauclt1.exe

ASR

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:

Starte einfach mal den Lizenzprotokollierdienst auf dem Server neu auf dem Fehler auftritt und auf dem Server mit dem er eine Verbindung herstellen will.

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

Now in the real world, devices fail, die, are re-formatted, etc. To mitigate this, a device CAL is automatically returned to the pool (by the license server) after a random period of 52-89 days if it's not renewed by the device.

Nach 52~89 Tagen sollte die Lizenz wieder im Lizenzpool in der Terminalserverlizensierung zu finden sein. Ich hoffe das bringt dich bischen weiter. :cool: