cyberax

Boah...Tomaten auf den Augen gehabt. zwischen ;Database=xxx;Trusted_Connection=yes; dem Datenbank namen und den ; war ein Leerzeichen drin oO

Hallo zusammen, vielleicht kann mir jemand von euch helfen. Dim adoDomDbConn As New ADODB.Connection Dim adoDomDbRec As New ADODB.Recordset Dim adxDBCat As New ADOX.Catalog Dim adxDBTable As New ADOX.Table Dim strCon As String With adoDomDbConn strCon = "Driver={SQL Server};Server=xxx;Database=xxx Trusted_Connection=yes" .Open(strCon) adxDBCat.ActiveConnection = adoDomDbConn adxDBTable.Name = "Test_Table" adxDBCat.Tables.Append(adxDBTable) .Close() End With Die Verbindung zur Datenbank wird ohne Probleme hergestellt, nur eine Tabelle kann ich nicht erstellen. Hat jemand eine Idee ? Vielen Dank Cyberax

Ne...der Thread ist auch mist... aber ich habs gefunden ;-) Ich habe das script immer vor dem echten Abschluss angehalten... lässt man es komplett durchlaufen..tada..excel zu^^ Klappt jetzt sogar wenn ein Excel schon offen war... dann schließt sich nur das neue Excel.Objekt nicht das alte

Hallo zusammen, wenn man per - objExcel = CreateObject("Excel.Application") ein ExcelObject erstellt. Wie schließt man es dann ? - objExcel.close - objExcel.quit alles erfolglos... Die Excel-Anwendung bleibt im Taskmanager bestehen. Ich kann Arbeitsblätter erstellen und speichern und schließen. Geht alles super..selbst wenn ich das Excel-Objekt sichbar machen und ein close / quit auslöse, wird es geschlossen, aber es bleibt im Taskmanager bestehen^^... Vielen Dank für eure hilfe

Danke... das wars...die Funktion kann man ausreichend modifizieren Vielen dank für eure Hilfe

Hallöchen zusammen, gibt es eine Möglichkeit ein FileSearch zu machen, ohne ein sich ein Excel-Objekt erzeugen zu müssen ? Wichtig sind halt die eigentlich des FileSearch SearchSubFolder = true TextOrProperty = "*.inf" Programmiert wird in Visual Basic 2008 Express Edition... am liebsten ohne Excel oder sonstige Verweise...da ich nicht weiß, ob ein Excel überhaupt installiert ist auf den Clientsystemen.

Ist eigentlich kein Problem, wenn du die Möglichkeit hast Remote auf alle Maschinen zu kommen ;-) Das Programm certmgr.exe von MS sollte dir helfen. Genialer ist das hier: Install certificates remotely Beispiel Script-Zeile: CStore.vbs import -s CA -l lm Zertifikat.cer Remote auf alle Maschinen fertig^^

Hallo janlutmeh, gpresult zeigt eher an, dass alles i.O. ist :-( Ich lade die Datei mal hoch (gpo.txt) Die beiden Policys - C-KW-G-0000-ADM-Laptop2003 - U-KW-G-0000-ADM-User2003 sind aktiv und greifen prinzipiell auch: C-KW-G-0000-ADM-Laptop2003 macht hierbei die Computereinstellungen U-KW-G-0000-ADM-User2003 die Usereinstellungen. Leider ist der Teil: HTTP-Proxyserver: ###:80 Secure-Proxyserver: ###:80 FTP-Proxyserver: ###:80 Gopher-Proxyserver: ###:80 Socks-Proxyserver: ###:80 Falsch, dass der Proxy der hier steht, der lokal Eingetragene ist und nicht der in der GPO eingetragene !!! Warum auch immer, für diesen Teil der IE Konfiguration greifen die GPO's nicht. Ich hoffe, jemand hat eine Idee hierzu ? gpo.txt

keiner eine Idee :-( Dann sind Gruppenrichtlinien im AD doch nicht so toll wie ich dachte

Mh...ok^^ Bei XP / Server 2003 Start - Einstellungen - Verwaltung - Lokale Sicherheitsrichtlinie Lokale Richtlinien - Zuweisen von Benutzerrechten - Auf diesem Computer vom Netzwerk bla bla Ereignissprotokolle: Start - Einstellungen - Verwaltung - Ereignisanzeige

Das ist ein Rechteproblem vom Client aus, der kann sich nicht am Server melden. Bitte kontrollieren: Auf dem Server gibt es ein Verzeichnis: - UpdateServicesPackages und - WsusContent auf beide hat JEDER lesenden Zugriff in der Webfreigabe und im NFTS der Netzwerkdienst mit VOLLZUGRIFF auf den Ordner - WsusContent und Lese / Schreibzugriff auf den Ordner - UpdateServicesPackages Dann in den Lokalensicherheitsrichtlinien brauchen die User -IUSR_* und der - IWAN_* das Recht: "Auf diesem Computer vom Netzwerk aus zugreifen" Den IIS so konfigurieren, dass der Anonyme Zugriff aktiviert ist und der IUSR_* drin steht incl. dem Hacken der Integrierten Windows Authentifizierung. Nen Proxy haben deine Clients nicht oder ? Eventlog des Server mal prüfen..

zusatz.... eventuell auch noch die Einstellungen in den Gruppenrichtlinien, vielleicht hast du dort was übersehen ?

Klares nein... ich habe das selbst auch schon gemacht. Die Einstellung sind nur auf dem Server und ob man nun den WSUS per MMC oder WEB-Interface nutzt hat rein gar nix mit den Clients zu tun. Könntest du mal die ReportingEvents.log posten und die Windowsupdat.log in aktueller Version ?

Der Dienst "wuauserv"...exisitert vermutlich als "Automatische Updates" in der Diensteliste ? (aufrufen mit services.msc) Dieser sollte auf automatisch stehen und laufen...sonst hast du ein Problem.

Ich hatte mal, das Problem, dass der WSUS die Namens auflösung nicht richtig hinbekommt. Besonders wenn man mit unterschiedlichen Suffixen arbeitet. Daher habe ich die IP-Addresse des WSUS eingetragen und nicht den Namen. Dann lief alles bestens. Eventuell hilft auch ein Reset des Updates Dienstes. Dazu gibt es das Tool "bitsadmin.exe" Downloaddetails: Windows XP SP2 Supporttools für fortgeschrittene Benutzer einfach mit den Optionen - bitsadmin.exe /RESET /ALLUSERS einmal ausführen. Du solltest davor allerdings den Dienst - wuauserv beenden und nach der Aktionen neustarten und dann mit wuauclt /detectnow eine sofortige Rückmeldung auslösen. Fals die Regwerte lieber sind, steht das unter HKLM SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update "NextDetectionTime" "ScheduledInstallDate" "LastSuccessTime" "LastError" nicht vergessen, den Dienst davor zu stoppen...regwerte auf einen Wert in der Vergangeheit ändern...dienst starten...fertig und dann die Log-Files analysieren WindowsUpdat.log im Windows-Verzeichnig und die ReportingEvents.log im SoftwareDistribution-Ordner Gruß Cyberax