Sunny61

Wenn die Geräte in die Domain kommen, brauchst Du das Script gar nicht.

Neuen Server installieren, in die Domain aufnehmen, Windows Updates installieren. DNS prüfen, der 1. DNS Server muss auf den bisherigen DC/DNS-Server zeigen. Server zum DC raufstufen. Nach dem Neustart trägst Du ihn selbst als *zweiten* DNS Server bei sich selbst ein, der erste DNS zeigt immer noch auf den alten. Windows Updates installieren, falls fällig. Replikation prüfen, wenn möglich beide Server für eine Nacht zusammen stehen lassen. Der zweite Server dann durch entfernen der Rolle bzw. mit Hilfe von DCPROMO zum Memberserver herabstufen. Vor dem Neustart in den IP-Einstellungen den zweiten neuen DC als 1. DNS eintragen, Neustart. Im SnapIn Standorte und Dienste prüfen ob der alte Server noch als DC auftaucht, wenn ja, löschen. Wenn Du den alten zum Memberserver degradiert hast, kannst Du auch auch abschalten und aus dem AD löschen. Vorher müssen natürlich alle anderen Rollen noch übertragen werden.

Was spricht gegen warten? Ist es zwingend notwendig den Level jetzt gleich/sofort anzuheben?

Ist die Firmware auf dem Router aktuell? Ist dort DHCP aktiv? Wenn ja, abschalten. Wenn nein, auf dem Server DHCP sauber konfigurieren. Das ist kein Gerät für eine Firma, so etwas hat man vielleicht zu Hause.

Was ist das für ein Gerät das als Standardgateway fungiert? Exakte Bezeichnung und exakte Firmwareversion bitte posten. BTW: Nettweise schreibt man ohne ß. ;)

Konfiguriere das SMB-Signing gem. Best Praxis in den beiden Default Domain Policies. http://www.gruppenrichtlinien.de/artikel/smb-signing-kommunikation-digital-signieren/ IMHO kommt das auf den Empfänger an, wenn der V1 nicht kann oder kennt, nützt dir das wenig. Auch hat das nichts mit der Domain zu tun, sondern mit dem empfangenden OS. Hast Du dem Techniker die korrekten Daten denn schriftlich geliefert? Versuch dich, in seine Lage zu versetzen. Dokumentiere am besten gleich alles von diesen Geräten, mit Datum und gänderten Zugangsdaten abspeichern und ausdrucken. Dann kann beim nächsten Mal nichts mehr passieren. ;)

Benenne die .cmd doch mal um und teste nochmal mit den Autoruns. Wird die .cmd dann immer noch zweimal ausgeführt?

Nimm das Teaming komplett raus, deaktiviere eine NIC, geht es dann besser? Es sollte zum Test wirklich nur eine NIC aktiv sein.

Durchsuche auch das SYSVOL nach der Datei, kommt sie öfters vor? STRG + F3 > und jetzt nach *.ENDUNG durchsuchen. Nicht manuell suchen oder glauben man weiß es besser, automatisch suchen lassen. Das hattest Du schon geschrieben. Steht das Script evtl. in der RDP-Datei? Leg doch mal eine neue RDP-Datei an, explizit darin nichts verknüfen lassen. Lokale Umleitungen rausnehmen.

Man sich mit den Exchange.WebServices sicherlich ein Programm schreiben, das jede eingehende Mail 'zählt', geht sicherlich auch per Transportregel. Und ab einer bestimmten Menge dann auch eine Mail verschicken. Mir ist kein Tool bekannt, das so etwas out of the Box kann.

Hat das evtl. jemand auf dem TS via GPEDIT.MSC manuell eingestellt? Du kannst auch das SYSVOL nach der Datei durchsuchen, kommt sie öfters vor?

Wenn es Geräte von Betriebsfremden sind, die aber trotzdem Zugriff brauchen kriegst Du die Geräte nicht in die Domain. Ist manchmal so.

In einer Command müsste das funktionieren: net use \\deinDC "passwort" /user:deinedom\externerBenutzer Alternativ "passwort" weglassen, dann müssen sie es eintippen.

Dann kann doch eigentlich nur Loopback aktiviert sein, prüf das doch nochmal.

Du mußt es andersrum sehen, es macht keinen Sinn die Daten *NICHT* zu verschlüsseln. Man kann nicht früh genug anfangen mit der Verschlüsselung, natürlich auch im internen LAN.

Es gibt von Access 32- und 64-Bit Versionen. Auch auf einem 64-Bit OS sollte man immer auf die 32-Bit Version von Office zurück greifen. Bei den ODBC-Treibern mußt Du auf 64-Bit Systemen aufpassen dass Du immer den richtigen ODBC-Treiber erwischt. Auszug aus: http://support.microsoft.com/kb/942976 Die 32-Bit-Version der Datei "Odbcad32.exe" befindet sich im Ordner "%systemdrive%\Windows\SysWoW64". Die 64-Bit-Version der Datei "Odbcad32.exe" befindet sich im Ordner "%systemdrive%\Windows\System32".

Hmm, kommt mir bekannt vor: http://social.Technet.microsoft.com/Forums/de-DE/windowsserver8de/thread/00ddff7b-a7dd-4d42-b2b0-83415075f7d2#00ddff7b-a7dd-4d42-b2b0-83415075f7d2 Dort darfst Du auch gerne auf diesen Thread hier hinweisen. In den hiesigen Board-Regeln http://www.mcseboard.de/topic/191452-regeln steht in No. 19, das Du auf die anderen Threads zum gleichen Thema hinweisen darfst. Für zukünftige Crosspostings wäre es also nicht schlecht darauf hinzuweisen, Danke. ;)

Und welche Meldungen finden sich im Eventlog? Es gibt übrigens auch eines für die Gruppenrichtlinien.

OK, das wäre möglich. Zumindest hat er schon in die Technet Foren geschafft, dort hat sich die Resonanz in Grenzen gehalten.

Wenn es dem Kunden nicht wichtig ist, dass lass es doch bleiben. Oder ist es doch nur ein Projekt in der Berufsschule? Ansonsten hast Du sicherlich einen Server in deinem Bestand, dem Du dem Kunden auf die Schnelle hinstellen kannst.

Bei dir ist jede Information vollkommen umsonst. Wenn Du solche Dinge nicht weißt, gib dem Kunden eine Chance zu überleben und lass endlich jemanden ran der Ahnung hat.

Lass einfach jemanden ran der Ahnung hat, Du qualifizierst dich mit jedem Posting mehr zum Amateur.

Das haben wir ihm nun wirklich oft genug erzählt, er will es einfach nicht verstehen.

Wenn der DC beim chkdsk abraucht, was machst Du dann? Hast Du eine Sicherung des SYSTEMSTATE das Du auch erfolgreich zurück gesichert hast? Wäre nicht das erste Mal, das beim chkdsk eine oder mehrere Platten den Geist aufgeben. Das ist richtig Stress für die Platten.

Ganz wichtig ist auch die Firmware auch solchen Geräten. Immer aktualisieren. Wir hatten da auch schon die größten Merkwürdigkeiten.