Maraun

Hi, also mein Problem ist, dass interne Benutzer, die Zugriff auf das externe Kollaborationsportal haben, in die interne IPv4 Eigenschaften die externen DNS Suffixe eintragen. Ich setze ja per GPO unsere interne Domäne als DNS Suffix und das ist ja nicht sichtbar, aber ich möchte dennoch Auflösungsprobleme mit den externen DNS-Suffixen verhindern und diese auch nicht setzen lassen. Deshalb verhindere ich auch die DNS Suffix Suchliste. Bei unseren lokalen Clients, die mit dem externen Portal verbunden waren, sehen die TCP/IP Einstellungen jetzt so ähnlich aus wie in meinem angehängten Beispiel. Gruß Alex

Hallo zusammen, wir haben eine Kollaboration mit einem anderen Unternehmen und dafür für einige Benutzer deren Portalzugriff auf Sharepoint etc. in Nutzung. Jetzt habe ich gesehen, dass bei unseren Clients mit dem externen Portalzugang deren DNS-Suffixe in den lokalen Netzwerkeinstellungen drinstehen. Wie kann ich das zukünftig verhindern? Ich habe folgende GPOs bereits gesetzt, trotzdem wurden diese fremden DNS-Suffixe eingetragen -> Siehe Screenshot...(ausgeschwärzt ist unser DNS Suffixe der Domäne). Gruß

Hi zusammen, danke für die Antworten. Das mache ich. Wenn ich Fakten habe, werde ich mich gegebenenfalls nochmals melden. Grüße

Hallo zusammen, wir sind kürzlich aufgekauft worden und befinden uns in einer Konsolidierungsphase. Unser AD (Forest/Domain 2008 R2) muss mit Exchange 2010 wahrscheinlich in naher Zukunft per Trust an die bestehende Domäne (habe noch keine Infos zum dortigen technologischen Stand) angebunden werden. Ob direktional/bi-direktional etc., keine Ahnung. Zunächst wird mal eine direkte VPN-Site-to-Site Verbindung vorbereitet und eingerichtet. Dann geht es schrittweise weiter. Auch wenn es eine Cross-Frage ist, aber: Ich müsste dann wohl auch die bestehenden Exchange-Adressen (Gegenstelle nutzt wohl Office 365/Cloud) ins unser globales Adressbuch importieren (seperates Adressbuch) udn anders rum (exportieren udn zur verfügung stellen). Wollte mich mal vorab erkundigen, wer sowas schon mal hat machen müssen und was so Stolperfallen sind/wären. Viele Grüße und Danke vorab

Hallo zusammen, ähnlich wie lionheart, der gestern ein Problem mit DNS mit der DNS Aktualisierung gepostet hat, geht es mir auch. Bei uns sind trotz dynamischer Updates aus dem DHCP utnerschiedliche IPs für Workstations vergeben. IM DHCP stimmt die IP, die per noch gültiger Lease vergeben ist. Im DNS steht noch ein alter Eintrag drin. Wir haben Domain Level 2008 R2, mit 2012er Domaincontrollern und einem physischen 2008 R2 DC. Einer der 2012er DC´s ist auch der DHCP Server. Wir haben eine AD-integrierte Zone und lassen nur sichere Updates zu. Im DHCp ist das dynamische Update konfiguriert, mit der Option Immer automatisch updaten. Siehe Screenshot. In den IPv4 Optionen des DHCP sind unter Erweitert Anmeldeoptionen vergeben (testweise seit heute mein Domain Admin). Vorher waren hier der User und das Domainfeld leer. Wenn ich mir jetzt im DNS unter Security die Rechte anschaue, dann steht dort aber nirgends der jeweilige Client mit Read/Write, für das erfolgreiche Update. Everyone und Self nur mit speziellen löeserechten. Nur Domain Admisn dürfen schreiben. Wie/Wo setze ich die Rechte im DNS für das erfolgreiche Update durch das Computerobjekt? -> Einfach im DNS auf der Forward Lookup Zone/Properties/Security unter SELF Read und Write aktivieren? Sollte das die Lösung sein, ich habe das Aging nicht an bei unsere DNS-Zonen, da wir ne Menge alter Servernamen und Aliase mitschleppen. Wie kriege ich dann die alten und falschen DNS-Einträge für die Clients wieder erneuert? Löschen? Viele Grüße

Tja, ich bin eben nicht der Entscheider. Und wenn nun alle meine Vorstöße verpuffen und es eben anders gesehen wird, dann muss ich dem Folge leisten und die Aufgabe umsetzen.

Hi Nils, ich habe dazu bereits mal zwei Threads aufgemacht. Man hat sich damals bei der Erstellung leider für ne .ads Domain entschieden, die jetzt Google innehat. Erwähnt sei hierbei, dass ich zunächst nur mal den zusätzlichen DC in der neuen Domäne testen möchte. Weitere Schritte sind zumindest bis jetzt nicht geplant. http://www.mcseboard.de/topic/207072-active-directory-tld-%C3%A4nderung/?hl=%2Bmaraun&do=findComment&comment=1301337 http://www.mcseboard.de/topic/209701-zus%C3%A4tzliche-root-domain-sukzessiver-umzug/?hl=%2Bmaraun&do=findComment&comment=1326430

Hallo zusammen, wir haben uns (lange vor meiner Zeit) für einen falschen Domänennamen entschieden und sind daher (eventuell) zum Domänenumzug genötigt. Ich wollte kurz den Ist-Zustand und meine geplante Umstellung hier mit Euch durchsprechen. Zustand: Domäne 2008 R2 (Domain- / Forestlevel) 3 DC´s in Domäne1 (DC-Domäne1), 1DC in Domäne2 (DC in Domäne2) Netzwerkkonnektivität der DC´s ist vorhanden -> DC Domäne1 kann DC Domäne2 per IP pingen, DC Domäne2 kann DC Domäne 1 per IP und FQDN pingen In Domäne1 gibt es noch eine DNS-Zone, die namentlich unseren neuen Domänennamen hat. Diese habe ich bereits 1zu1 auf den neuen DC in Domäne 2 umgezogen. Plan: Nachdem die DNS-Zone, die den Domänennamen innehat, komplett umgezogen (Domäne2) und gesichert wurde, wird diese in Domäne1 gelöscht. In Domäne 1 erstelle ich für die Domäne2 (und gleichzeitig die gelöschte DNS-Zone) eine bedingte Weiterleitung auf den neuen DC Domäne2. Danach erstelle ich einen Domain-Trust zwischen dem DC FSMO-Halter Domäne1 und dem DC Domäne2. Im Anschluss teste ich die Namensauflösung einzelner Systeme, für die laut DNS dann der DC Domäne2 zuständig ist. Passt das vom Ablauf her so? Danke vorab für alle Beteiligungen.

Also für die VM´s in VMWare ist der Zeitabgleich deaktiviert. Hab jetzt bei dem betreffenden DC ein rediscover gemacht, jetzt zeigt er als Source wieder den PDC an. Komisch, wie das sich auf Local CMOS stellen konnte.

Hallo zusammen, wir nutzen in der Produktion spezielle BDE-Terminals mit Windows, die auf einen zentralen 2012er Server zugreifen, deren Zeit nicht mehr als mehrere Sekunden auseinander laufen darf. Ich habe im AD einen DC als Zeitserver mit ptbtime1.ptb.de definiert. Dies funktioniert soweit ganz gut, allerdings ief jetzt der zentrale Server für die BDE-Terminals um 2 Minuten vom Rest auseinander. Die Zeitconfig habe ich getestet und kann keinen Fehler erkennen: W32tm /config zeigt den DC als Zeitserver, In der Registry steht der Sync-Intervall auf 3600, also extrem gering. Was kann ich am 2012er Server noch testen/einstellen bezüglich der aktuellen Zeit? Update: Ein DC, der eigentlich seine Zeit beim PDC holen sollte und dies auch so meldet, bringt folgende Info bei dem Befehl: w32tm /query /source Local CMOS Clock Hier wird die lokale Uhr abgefragt, anstatt der PDC.

Einen für jeden im lokalen Outlook, falls das remote und per Powershell überhaupt möglich ist. Oder ich muss es eben über eine kleine Doku regeln, so dass es eben jeder selber macht. In diesden lokalen CRM Ordner werden dann alle gesammelten CRM-Kontakte synchronisiert/verarbeitet.

Hallo zusammen, wir nutzen Exchange 2010 mit Outlook 2010/2013. Für ein CRM-System gibt es die Aufgabe, einen zentralen Kontaktordner in der Ordnerroot zu erstellen, in dem dann die ganzen CRM-Kontaktdaten verwaltet und synchronisiert werden. Hat mir jemand einen Tipp,wie ich den Ordner per Powershell bei 120 User erstellen kann? Manuell wäre das: Im Outlook auf das Postfach, rechte Maus, neuer Ordner, Typ Kalender, Name CRM. Grüße Alex

Hallo zusammen, vielen Dank für die Antworten. @zahni: Das hatte ich befürchtet (dass Logonskripte erhalten bleiben)... @lefg: Soweit muss ich kommen. Wie oft gibt es Usertickets, nach dem Motto, ich habe keinen Zugriff, dabei fehlt einfach der Link auf "\\fileserver\verzeichnis". Denke, dass GPP´s mein Ansatz sein werden.

Hallo zusammen, wir nutzen für knapp 1400 Clients zum großen Teil noch Batch-Logonscripte, die im Sysvol Verzeichnis abgelegt werden. Der weitaus kleine Teil der Clients hat ein VBScript, das basierdend auf den AD-Zugriffsrechten die Laufwerke mapped. Die Batchdateien sind auch mit klassischen net use xyz: \\fileserver\verzeichnis aufgebaut, damit User die Abteilungsshares gemapped bekommen. Aber auch da können wir mittlerweile keinen Standard (jedes Share mit exklusivem Buchstaben für Gleichheit) gewährleisten. Ich plane schon lange, dies mal Umzustellen, habe aber ehrlich gesagt keine Ahnung, wohin die Reise gehen soll: Powershell-Scripte, Gruppenrichtlinien, etc. Wir nutzen lokal gespeicherte Benutzerprofile und haben etwa 1250 Windows 7 Clients, knapp 100 Windows 10 Clients und einige Veteranen/Exoten (NT, XP - Produktionsmaschinen). Kann vielleicht jemand mit Erfahrung dienen, was möglich ist hinsichtlich der Logonscripte oder hat vielleicht bereits jemand eine ähnliche Umstellung von statischen Logonscripten hin zu was neuerem bereits vollzogen? Vielen Dank vorab.

hi, also zertifikat am exchange und jetzt tmg passt mittlerweile. der client ist leider in Österreich und als Außendienstler nicht ständig greifbar. Sorry, für die unnötige Komplexität, aber schopn mal vielen Dank Euch beiden für die Geduld und die fundierte Hilfe. Sobald ich Neuigkeiten vom Client habe, kommt ein Update.

"Du müsstest das Zertifikat vermutlich mit dem Private-Key in der persönlichen Zertifikatsspeicher des TMG Servers importieren und dann im TMG an den Weblistener(?) binden." Ist so geschehen. Intern im OWA zeigt er mir jetzt das neue Zertifikat an. Also richtig von mir beschrieben war das nicht. Der installierte Windows 10 Client scheint einfach das alte Exchange Zertifikat im persönlichen Speicher zu haben und meckert dieses eben bei jedem Outlook Start an. Das ist ja das eigentliche Problem. Vergiss hierbei VPN, habe ich fälschlicherweise eingestreut.

Ein TMG, das lediglich für Webmail noch zuständig ist...und das mit Sicherheit noch das alte Zertifikat eingebunden hat. Aber warrum meckert ein Windows 10 Client aus der Domäne, der per VPN verbunden ist, das an? Kann ich das im Zertifikatsspeicher des TMG einfach tauschen? Habe auf dem TMG jetzt das gültige Zertifikat importiert und das alte Zertifikat gelöscht.

Komme leider gerade nicht auf den Client. Muss ich nachreichen. Was ich aber sagen kann ist, dass der Client da definitiv das veraltete Zertifikat (noch im lokalen Speicher hat) anzeigt, da er ja Ablaufdatum 10.04. meldet. Gültig von 11.04.2012 - 10.04.2017 Eventuell muss ich das Zertifikat mal auf dem Client löschen? Die Exchange-Server haben alle das gleiche Zertifikat, Seriennummer überall gleich. "Vielleicht ist es ein SHA1 Zertifikat" -> Ja, es ist ein SHA1 Zertifikat. Thumbprint Algorithm SHA1

Okay, hier die beiden Transportserver, die ja als einzige Services im Zertifikat haben. Und ein Postfacherserver Screenshot.

Okay, gerade gesehen: Die Transportserver haben folgende Dienste: IIS, SMTP, POP und IMAP Die Mailbox-Server haben als Services: None Wir haben 2x Hub Transport, Client Access, Mailbox und 2x Mailbox Befehlsausgabe bei einem der Transportserver, siehe Anhang.

Ja, wie vorher bereits geschrieben: IMAP, POP, IIS, SMTP Gleicher Name, webmail.domain.com. Certificate Status ist okay, valid von 16.03.2017 bis 15.03.2022. Hab jetzt zwei Surfaces gecheckt: Einer hat das Zertifikat im eigenen Benutzerspeicher, der andere nicht. Beide starten ohne Fehlermeldung.

Ja und das neue Zertifikat habe ich auf den Exchange-Servern ja auch vor Wochen erstellt. Ich habe hier zwei Clients, ein Client (Win7) hat das alte abgelaufene Exchange-Zertifikat im Benutzerzertifikatsspeicher und startet Outlook 2010 ohne Fehlermeldung, ein Win10 Client hat das Zertifikat nicht im eigenen Benutzerzertifikatsspeicher und startet ebenso ohne Probleme Outlook 2013. Wird das Zertifikat da benötigt? Warum meckern nur zwei Clients von 1500?

Wir nutzen die Root CA für WLAN intern. Extern wird nichts mehr genutzt, außer ein wenig Webmail (mit dem Vertrauensfehler). Devices verbinden sich per MDM. Jeder Client hat das zentrale Root-CA Zertifikat mit Zeichenkette im Speicher. Daher sollte der Trust kommen, aber ich checke das mal. Ansonsten habe ich nachgelesen, dass das auch per GPO gehen sollte.

Naja, ich meinte damit, dass ich das Zertifikat per interner Root CA ausgestellt habe. Also der Exchange sieht es als SelfSigned False an. Kann ich das Zertifikat so weiter nutzen? Vor 5 Jahren wurde die 2010er Exchange-Server so in Betrieb genommen und da initial das Zertifikat verteilt. Ja, wir haben das Software LoadBalancing und beide Transportserver haben auch die CAS-Rolle. Die Frage ist, wie kann ich das neu ausgestellte Zertifikat jetzt an alle Clients verteilen? Root-CA? GPO?

Hi Doso, so wie beschrieben ist es auch. Müsste ich hier manuell alle Zertifikate tauschen? Per GPO?