Sunny61

Meinst Du so in etwa? ;) Da ist 'Handarbeit' angesagt. Rechts unten auf Zitieren, und jetzt immer mit der ersten Zeile und der letzten Zeile Blöcke beginnen bzw. abschließen.

Das Script ist sicherlich ein Anfang: http://gallery.technet.microsoft.com/scriptcenter/VB-Script-to-Check-and-620579cd Evtl. findest Du hier noch weitere Scripte: http://gallery.technet.microsoft.com/scriptcenter/site/search?f[0].Type=RootCategory&f[0].Value=windowsupdate&f[0].Text=Windows%20Update

@Daniel, wenn ich das richtig lese geht es nicht um den TS:

Ähnlich ist nicht gleich und fremde Threads kapert man nicht. Mach bitte einen eigenen Thread mit allen Informationen auf, Danke.

Gut, viel Erfolg und gib Bescheid was die Lösung war, Danke. ;)

Ist sicherlich auch eine Belastung für den Master-WSUS und dessen SQL Datenbank. Die Computerkonten liegen auf dem Master natürlich auch, den Download der Updates kannst Du steuern, Optionen > Dateien und Sprachen. Dort beim Downstream den richtigen Haken setzen, dann holt der sich die Updates bei MSFT. Du brauchst sicherlich Client-CALs für die zugreifenden Clients auf deinen Server. Du kannst sicherlich alle Updates genehmigen per Script, die von den Clients angefordert wurden. Dann bist Du auf der sicheren Seite. Wenn es viele Clients sind, würde sich evtl. ein eigener WSUS auszahlen, mußt halt auch ein eigenes GPO dafür erstellen. Eine offizielle Prozedur hab ich dafür noch nicht gefunden.

Den Foundation gibt es nur in Kombination mit der Hardware: http://www.golem.de/news/windows-server-2012-vier-editionen-aber-kein-windows-home-server-1207-93008.html Zumindest ist das gemeint mit 'wird nur an OEM-Hersteller lizenziert'. Deshalb gibt es davon auch keine Testversion.

Bezüglich der 32/64-Bit Problematik kannst Du nach diesem Artikel vorgehen: http://www.faq-o-matic.net/2010/01/06/windows-druckserver-treiber-fr-32-und-64-bit-clients/

Viel Erfolg! ;)

Wo die Konfigdateien gespeichert werden, weiß ich nicht. Aber in einem GPO kannst Du natürlich mit Variablen arbeiten. %APPDATA%\IBM ... wäre schon mal ein Anfang. Was soll dir das nicht schreiben erlauben auf c:\ denn bringen? Sind die User Admins? Wenn sie normale Benutzer sind, dürfen sie ja nur in ihr Benutzerprofil schreiben. Weshalb sollen sie dorthin nicht schreiben dürfen? Wenn alles korrekt konfiguriert sind, brauchst Du IMHO diese Einstellung gar nicht.

Da gibt es zig Angebote, hier ein paar davon: http://it-training.netlogix.de/zertifizierungen/microsoft/certified-solutions-associate/mcsa-windows-server-2012 http://www.pc-college.de/seminare-schulungen-kurse/mcsa/mcsa-mcsa-ms-windows-server-2012-komplettausbildung-mc2.php http://www.firebrandtraining.de/kurse/microsoft/mcsa/windows-server-2012-zertifizierung http://www.newhorizons.com/localweb/default.aspx?groupid=518

Kannst Du das evtl. in den Eigenschaften von Client Access konfigurieren? Alternativ eben den Pfad in das eine Verzeichnis per GPO wieder freigeben.

Das liegt IMHO am PDF-Drucker. Welcher PDF-Drucker ist installiert? Hast Du schon ein neues Benutzerprofil probiert?

Achtung, nicht jedes kann verwendet werden: http://support.microsoft.com/kb/916196/de :) Tja, wenn man im Februar 2014 noch auf XP setzt, ist man nicht ganz unschuldig. ;) BTW: Lies doch einfach mal: http://www.prime-expert.com/articles/a01/installing-windows-xp-with-f6-ahci-raid-drivers-from-dvd-without-floppy-drive.php http://www.intel.com/support/de/chipsets/imsm/sb/cs-029958.htm BTW2: Es gibt sicherlich auf dem Board noch den passenden Anschluß, dir fehlt einfach nur das Kabel zum Floppy und vielleicht das Floppy selbst. ;)

Bei der Installation von XP kann man gleich zu Beginn Treiber über hinzufügen. F6 hilft an dieser Stelle und ein Diskettenlaufwerk mit den Treibern auf einer Diskette. Du wirst den Unterschied von IDE zu SATA nicht merken. Also kannst Du es ruhig so lassen.

Das könnte dann so aussehen. REM Batch Datei um FTP automatisiert zu starten. ftp -v -n -i -s:\\Server\Pfad\Daten.txt Und hier der Inhalt der Daten.txt: open ftp.server.tld user DeinFTPUser FTPUserPasswort binary mput Hier kommen deine Befehle rein, das kann natürlich alles FTP-Mögliche sein. quit

Dann mach doch hier weiter: http://www.mcseboard.de/topic/197082-replikation-zwischen-dcs-nicht-mehr-m%C3%B6glich/?do=findComment&comment=1223064

Betrifft das nur Benutzer auf diesem Rechner? Oder nur einen bestimmten Benutzer auf diesem Rechner? Wenn ja, Benutzerprofil neu erstellen.

Ich schrieb auch *Benutzerprofil*. Welcher AV-Scanner ist im Einsatz? Deaktivieren hilft nicht, ist wie Augen zumachen und sagen 'ich bin unsichtbar'. Deinstallieren und anschließend mit dem Removal Tool des Herstellers drüber gehen.

Benutzerprofil des Benutzers neu erstellen. Gibt es das Problem auch in OWA?

Ich bin jetzt nicht der AD Spezialist, aber IMHO solltest Du bei diesem Fehler anfangen: Der Replikationsvorgang ist fehlgeschlagen, da Schemas unter den beteiligten Servern nicht bereinstimmten. Weiters kannst Du dir das SMB-Signing gem. BestPraxis anschauen, falls notwendig manuell lokal anpassen. http://www.gruppenrichtlinien.de/artikel/smb-signing-kommunikation-digital-signieren/

Zusätzlich zum Hinweis von zahni sei noch angemerkt, der SBS2011 hat noch bis 2020 Support, das sind also noch ein paar Jahre Ruhe. Nur bei Neukunden wirst Du dir etwas anderes überlegen müssen. Aber auch das findest Du in den schon vorhandenen Threads zu diesem Thema.

Freut mich für Dich und Danke für die Rückmeldung. ;)

Ich korrigiere mal den Link. ;) http://www.microsoftvirtualacademy.com/offers/virtualizationsquaredoffer#?fbid=T7J5iYAKkL5

So funktioniert es: Select * from TProtokoll WHERE fldDatum >= Convert(datetime2,'2014-02-25 05:00:00') AND fldDatum <= Convert(datetime2,'2014-02-25 08:00:00') EDIT: Alternative: Select * from TProtokoll WHERE fldDatum Between Convert(datetime2,'2014-02-25 05:00:00') AND Convert(datetime2,'2014-02-25 08:00:00')