29
Active Directory ohne Exchange Server
Hallochen Gemeinde!
In einem SBS2011-gestütztes Netzwerk ist der installierte Exchange Server 2010 SP1 seit ca. einem halben nicht mehr in Betrieb, weil bereits auf Horde Groupware und postfix/dovecot umgestellt wurde. Nunmehr soll der deaktivierte Exchange Server deinstalliert werden. Aber nicht dessen reine Deinstallation bereitet vorbereitende "Kopfschmerzen", sondern die Tatsache, dass sich ein Exchange Server tief in das Active Directory eingräbt. Und gerade die Exchange-Schema-Erweiterungen verhindern beispielsweise eine fehlerfreie Replikation, wenn Samba DC's integriert werden sollen. Das allenthalben lesbare Statement, dass diese Schema-Erweiterungen nicht entfernt werden könnten, ist weder zufriedenstellend noch wirklich akzeptabel. Immerhin ist - gegebenenfalls mit der "Brechstange" - wohl doch jedweder Eintrag wieder aus dem Active Directory entfernbar.
Gleichwohl sind über die reine Entfernung hinaus etwaige Auswirkungen zu erwägen. Daher würden mich Erfahrungswerte bei der vollständigen Beseitigung eines Exchange Servers aus einem Active Directory einschließlich Schema-Erweiterungen interessieren. Wer hat das bereits umgesetzt?
HansDampf06
In einem SBS2011-gestütztes Netzwerk ist der installierte Exchange Server 2010 SP1 seit ca. einem halben nicht mehr in Betrieb, weil bereits auf Horde Groupware und postfix/dovecot umgestellt wurde. Nunmehr soll der deaktivierte Exchange Server deinstalliert werden. Aber nicht dessen reine Deinstallation bereitet vorbereitende "Kopfschmerzen", sondern die Tatsache, dass sich ein Exchange Server tief in das Active Directory eingräbt. Und gerade die Exchange-Schema-Erweiterungen verhindern beispielsweise eine fehlerfreie Replikation, wenn Samba DC's integriert werden sollen. Das allenthalben lesbare Statement, dass diese Schema-Erweiterungen nicht entfernt werden könnten, ist weder zufriedenstellend noch wirklich akzeptabel. Immerhin ist - gegebenenfalls mit der "Brechstange" - wohl doch jedweder Eintrag wieder aus dem Active Directory entfernbar.
Gleichwohl sind über die reine Entfernung hinaus etwaige Auswirkungen zu erwägen. Daher würden mich Erfahrungswerte bei der vollständigen Beseitigung eines Exchange Servers aus einem Active Directory einschließlich Schema-Erweiterungen interessieren. Wer hat das bereits umgesetzt?
HansDampf06
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 618407
Url: https://administrator.de/contentid/618407
Printed on: April 23, 2024 at 23:04 o'clock
29 Comments
Latest comment
Eine Schemaerweiterung kann man nicht entfernen. Ist bei LDAP normal. Rein ja, raus nein.
Moin Hans,
wäre es nicht vielleicht Sinnvoll den alten SBS komplett auf das Abstellgleis zu bringen? Wäre sicherlich an der Zeit.
Grüße
wäre es nicht vielleicht Sinnvoll den alten SBS komplett auf das Abstellgleis zu bringen? Wäre sicherlich an der Zeit.
Grüße
Hallo.
Und der Windows Server 2019 Essentials (komplett ohne Exchange) ist ja relativ erschwinglich.
Wäre eine (wenn auch komplexe) Migration von MS AD zu Samba AD denkbar?
Gruß
Radiogugu
Zitat von @falscher-sperrstatus:
wäre es nicht vielleicht Sinnvoll den alten SBS komplett auf das Abstellgleis zu bringen? Wäre sicherlich an der Zeit.
wäre es nicht vielleicht Sinnvoll den alten SBS komplett auf das Abstellgleis zu bringen? Wäre sicherlich an der Zeit.
Und der Windows Server 2019 Essentials (komplett ohne Exchange) ist ja relativ erschwinglich.
Wäre eine (wenn auch komplexe) Migration von MS AD zu Samba AD denkbar?
Gruß
Radiogugu
Zitat von @radiogugu:
Und der Windows Server 2019 Essentials (komplett ohne Exchange) ist ja relativ erschwinglich.
Wäre eine (wenn auch komplexe) Migration von MS AD zu Samba AD denkbar?
Zitat von @falscher-sperrstatus:
wäre es nicht vielleicht Sinnvoll den alten SBS komplett auf das Abstellgleis zu bringen? Wäre sicherlich an der Zeit.
wäre es nicht vielleicht Sinnvoll den alten SBS komplett auf das Abstellgleis zu bringen? Wäre sicherlich an der Zeit.
Und der Windows Server 2019 Essentials (komplett ohne Exchange) ist ja relativ erschwinglich.
Wäre eine (wenn auch komplexe) Migration von MS AD zu Samba AD denkbar?
Genau dahin soll die Reise gehen. Nur bedingt das SBS-Konzept der Eier-legenden-Wollmilchsau, dass der SBS als zentrale Sammelstelle aller Serverdienste vorher komplett entkernt wird. Eine Zwischenstation über irgendeine andere Windows-Server-Version soll dabei vermieden werden.
Leider ist es so, dass die Aufnahme eines Samba BDC, der künftig zum PDC werden könnte, bisher misslingt, weil die rund 500 Exchange-Erweiterungen eine erfolgreiche Replikation verhindern. Im Internet sind zwar durchaus Migrationsbeschreibungen zu finden. Aber bei genauerem Hinsehen sind in diesen Fällen ein Exchange beziehungsweise dessen Erweiterungen nicht erwähnt oder es wird ganz allgemein darauf hingewiesen, dass für produktive Samba-AD-Umgebungen der Einsatz von Exchange nicht empfohlen wird. Die Baustelle Exchange kommentiert samba.org seit nunmehr mehr als acht Jahren mit "Exchange support - Development - Very much a work in progress"; ich erwarte nicht, dass sich das kurzfristig ändern könnte.
Zitat von @tikayevent:
Eine Schemaerweiterung kann man nicht entfernen. Ist bei LDAP normal. Rein ja, raus nein.
Eine Schemaerweiterung kann man nicht entfernen. Ist bei LDAP normal. Rein ja, raus nein.
Das ist schon klar. Mir geht es, um es zu präzisieren, letztlich darum, dass die erfolgreiche Replikation mit einem Samba BDC nicht mehr an diesen Exchange-Erweiterungen scheitert.
1. Kann diesbezüglich das Attribut "IsDisfunct" eine Hilfe sein, also werden deaktivierte Schemaelemente nicht repliziert? Falls ja, sollten dann vorher bei allen Objekten die Werte, die zu dem jeweiligen Schemaelement gehören, gelöscht werden oder können diese so belassen werden? Ich würde eher zu einem Löschen tendieren.
2. Kann alternativ ein Samba BDC dazu bewegt werden, jegliche Schemaerweiterung zu replizieren? Falls ja, wie müsste dafür vorgegangen werden?
Stünde denn der Aufwand die AD Objekte in einem nackten, neuen Samba DC manuell zu erfassen im Verhältnis?
Wenn es hier um 20 Benutzer, ein paar PC und Drucker ging, wäre das wahrscheinlich der sinnigste Weg, bevor man jetzt auf biegen und brechen versucht eine Replikation ans Laufen zu bringen.
Wie groß wäre denn die Umgebung an der Stelle?
Gruß
Radiogugu
Wenn es hier um 20 Benutzer, ein paar PC und Drucker ging, wäre das wahrscheinlich der sinnigste Weg, bevor man jetzt auf biegen und brechen versucht eine Replikation ans Laufen zu bringen.
Wie groß wäre denn die Umgebung an der Stelle?
Gruß
Radiogugu
Hallo,
mehr als 75 User sind es nicht
Ich würde auch mit einem frischen AD anfangen.
Alternativ macht man ein PrepareAD auf einem Test-DC und vergleicht „vorher“ und „nachher“.
Gruß,
Jörg
mehr als 75 User sind es nicht
Ich würde auch mit einem frischen AD anfangen.
Alternativ macht man ein PrepareAD auf einem Test-DC und vergleicht „vorher“ und „nachher“.
Gruß,
Jörg
Zitat von @radiogugu:
Stünde denn der Aufwand die AD Objekte in einem nackten, neuen Samba DC manuell zu erfassen im Verhältnis?
Wenn es hier um 20 Benutzer, ein paar PC und Drucker ging, wäre das wahrscheinlich der sinnigste Weg, bevor man jetzt auf biegen und brechen versucht eine Replikation ans Laufen zu bringen.
Stünde denn der Aufwand die AD Objekte in einem nackten, neuen Samba DC manuell zu erfassen im Verhältnis?
Wenn es hier um 20 Benutzer, ein paar PC und Drucker ging, wäre das wahrscheinlich der sinnigste Weg, bevor man jetzt auf biegen und brechen versucht eine Replikation ans Laufen zu bringen.
Zitat von @117471:
mehr als 75 User sind es nicht
mehr als 75 User sind es nicht
Die Option eines Neuanfangs auf der grünen Wiese habe ich auch schon in Erwägung gezogen., zumal die Domäne ihren Ursprung bei einem SBS2003R2 hat. Da es aber eine produktive Umgebung ist, müsste die finale Umstellung letztlich doch für alle Member-Server und -Clients in einem Rutsch erfolgen? Das schließt aber nicht nur deren Abmelden bei der alten und das Anmelden bei der neuen Domäne ein, sondern erfordert zugleich solche Dinge wie SPN's im neuen AD nachtragen und keytab in der jeweiligen Serveranwendung neu erstellen. Das könnte vom reinen Zeitaufwand her schnell mehr als einen Tag Downtime bedeuten.
Meine größte Sorge gilt dabei den Benutzer- und Gruppenkonten, weil sich bei einem neuen Active Directory die ID's etc. unterscheiden. Ich müsste zudem wohl bei den SQL-Server-Datenbanken die gesamten Benutzerberechtigungen bei allen Objekten (händisch) anpassen oder neu vergeben.
Zitat von @117471:
Alternativ macht man ein PrepareAD auf einem Test-DC und vergleicht „vorher“ und „nachher“.
Alternativ macht man ein PrepareAD auf einem Test-DC und vergleicht „vorher“ und „nachher“.
Mir sagt prepareAD ehrlich gesagt nur etwas im Zusammenhang mit Exchange und dessen Schema-Erweiterungen. Exchange ist künftig aber nicht mehr im Rennen. Könntest Du das prepareAD in Deinem Sinne etwas näher skizzieren?
Hallo,
*Das* musst Du nun wirklich selber wissen
Ich habe es seinerzeit immer so gehandhabt, dass ich die neue Struktur parallel zur alten Struktur aufgebaut habe. Die neue Struktur war anfangs nur über einen RDP-Server erreichbar, auf dem ich die Dienste von der alten Struktur als Datenquelle genutzt habe.
Ein Outlook auf dem RDP-Server kann ja anfangs mit dem alten Exchange reden und dann irgendwann auf den neuen Kopano umgestellt werden
Eine Besonderheit waren die Fileserver. Hier habe ich turnusmäßig einen Sync mit Robocopy etabliert (nicht schön, aber selten).
Die Anwender waren zunehmend gezwungen, den neuen RDP-Server zu benutzen. Spätestens dann, wenn ich migrierte Dienste in der alten Struktur abgestellt habe
Das Ganze muss natürlich mit der Geschäftsführung abgestimmt sein und für die Mitarbeiter einen Nutzen bringen. Der Nutzen bei meinen Kunden war, dass die Mitarbeiter die neue Struktur (RDP-Server) von zu Hause aus nutzen durften. Wer macht nicht gerne HomeOffice
Richtig. Die Idee wäre, einen "nackten" 2008R2 hinzustellen und das Schema darzustellen. Dann lässt man das PrepareAD von einem Exchange drüberlaufen und guckt sich die Schemata im Vergleich an. Dann siehst Du ja, was dazugekommen ist und kannst zumindest schon einmal den Löschaufwand abschätzen.
Gruß,
Jörg
Zitat von @HansDampf06:
Da es aber eine produktive Umgebung ist, müsste die finale Umstellung letztlich doch für alle Member-Server und -Clients in einem Rutsch erfolgen?
Da es aber eine produktive Umgebung ist, müsste die finale Umstellung letztlich doch für alle Member-Server und -Clients in einem Rutsch erfolgen?
*Das* musst Du nun wirklich selber wissen
Ich habe es seinerzeit immer so gehandhabt, dass ich die neue Struktur parallel zur alten Struktur aufgebaut habe. Die neue Struktur war anfangs nur über einen RDP-Server erreichbar, auf dem ich die Dienste von der alten Struktur als Datenquelle genutzt habe.
Ein Outlook auf dem RDP-Server kann ja anfangs mit dem alten Exchange reden und dann irgendwann auf den neuen Kopano umgestellt werden
Eine Besonderheit waren die Fileserver. Hier habe ich turnusmäßig einen Sync mit Robocopy etabliert (nicht schön, aber selten).
Die Anwender waren zunehmend gezwungen, den neuen RDP-Server zu benutzen. Spätestens dann, wenn ich migrierte Dienste in der alten Struktur abgestellt habe
Das Ganze muss natürlich mit der Geschäftsführung abgestimmt sein und für die Mitarbeiter einen Nutzen bringen. Der Nutzen bei meinen Kunden war, dass die Mitarbeiter die neue Struktur (RDP-Server) von zu Hause aus nutzen durften. Wer macht nicht gerne HomeOffice
Mir sagt prepareAD ehrlich gesagt nur etwas im Zusammenhang mit Exchange und dessen Schema-Erweiterungen.
Richtig. Die Idee wäre, einen "nackten" 2008R2 hinzustellen und das Schema darzustellen. Dann lässt man das PrepareAD von einem Exchange drüberlaufen und guckt sich die Schemata im Vergleich an. Dann siehst Du ja, was dazugekommen ist und kannst zumindest schon einmal den Löschaufwand abschätzen.
Gruß,
Jörg
@117471: Zunächst besten Dank für die ausführlichere Darstellung. Ich werde diesen Ansatz auf jeden Fall im Hinterkopf behalten, weil ich dem zu einem späteren Zeitpunk als Bereinigungsansatz nachgehen will.
Aber das Replikationsproblem hat sich wohl in Luft aufgelöst. Unsere Diskussion hatte mich veranlasst, nochmals intensiv im Internet zu mehreren Gedanken zu recherchieren. Dabei stieß ich bei samba.org auf die Seite mit der Darstellung der Versionsentwicklung und las, dass seit Samba 4.1 die Replikation mit Exchange problemlos möglich sei. In Verwunderung darüber, weil meine BDC-Implementierungsversuche unter Ubuntu 16.04. und 18.04. trotz neuerer Samba-Version mehrmals genau an der Replikation gescheitert waren, suchte ich weiter zu den Exchange-Schema-Erweiterungen und stieß dann auf https://wiki.samba.org/index.php/Samba_AD_schema_extensions. Dort steht betreffend Schema-Erweiterungen: "In order to allow them, the option dsdb:schema update allowed must be set to true in the smb.conf or passed on the command line."
Gesagt getan: Die für den BDC schlummernde Linux-VM gestartet, aktualisiert und für die möglichst neueste Samba-Version schnell ein In-place-Upgrade auf Ubuntu 20.04. Danach die VM als AD-Member entfernt, als BDC hinzugefügt, kurze ergänzende Anpassung für den Servicestart einschließlich des vorstehenden Parameterhinweises und samba-ad-dc gestartet. Beim Promoting als BDC hatte es noch zwei Fehlermeldungen bei der Datenbankerstellung/-inhaltsübertragung gegeben, so dass ich erwartete, letztlich wieder eine fehlerhafte Replikation zu sehen.
Indes nichts dergleichen: samba-tool drs showrepl zeigte keine Fehler - alles war diesbezüglich "0". Dann replizierte ich alle fünf Partitionen nacheinander mit samba-tool drs replicate vom SBS auf den BDC manual. Alles lief prompt und fehlerfrei. Ebenso kann ich in den AD-Verwaltungstools auf dem SBS augenscheinlich auf alles auf dem BDC zugreifen und es ist zutreffend repliziert.
Warum nicht gleich so, frage ich mich selbst?! Aber egal! Nun kann ich endlich den Endspurt zum Abschuss des SBS einläuten.
PS: @117471 etc. - Inspiriert durch Eure Anregungen konnte ich letztlich das Replikationsproblem lösen. Um aber späteren Lesern dieser Diskussionsrunde einen direkteren Zugang zu geben, hebe ich nur diesen Beitrag hervor, ohne Eure Beiträge dadurch schmälern zu wollen. Sie enthalten wichtige Überlegungen im Gesamtkontext.
Aber das Replikationsproblem hat sich wohl in Luft aufgelöst. Unsere Diskussion hatte mich veranlasst, nochmals intensiv im Internet zu mehreren Gedanken zu recherchieren. Dabei stieß ich bei samba.org auf die Seite mit der Darstellung der Versionsentwicklung und las, dass seit Samba 4.1 die Replikation mit Exchange problemlos möglich sei. In Verwunderung darüber, weil meine BDC-Implementierungsversuche unter Ubuntu 16.04. und 18.04. trotz neuerer Samba-Version mehrmals genau an der Replikation gescheitert waren, suchte ich weiter zu den Exchange-Schema-Erweiterungen und stieß dann auf https://wiki.samba.org/index.php/Samba_AD_schema_extensions. Dort steht betreffend Schema-Erweiterungen: "In order to allow them, the option dsdb:schema update allowed must be set to true in the smb.conf or passed on the command line."
Gesagt getan: Die für den BDC schlummernde Linux-VM gestartet, aktualisiert und für die möglichst neueste Samba-Version schnell ein In-place-Upgrade auf Ubuntu 20.04. Danach die VM als AD-Member entfernt, als BDC hinzugefügt, kurze ergänzende Anpassung für den Servicestart einschließlich des vorstehenden Parameterhinweises und samba-ad-dc gestartet. Beim Promoting als BDC hatte es noch zwei Fehlermeldungen bei der Datenbankerstellung/-inhaltsübertragung gegeben, so dass ich erwartete, letztlich wieder eine fehlerhafte Replikation zu sehen.
Indes nichts dergleichen: samba-tool drs showrepl zeigte keine Fehler - alles war diesbezüglich "0". Dann replizierte ich alle fünf Partitionen nacheinander mit samba-tool drs replicate vom SBS auf den BDC manual. Alles lief prompt und fehlerfrei. Ebenso kann ich in den AD-Verwaltungstools auf dem SBS augenscheinlich auf alles auf dem BDC zugreifen und es ist zutreffend repliziert.
Warum nicht gleich so, frage ich mich selbst?! Aber egal! Nun kann ich endlich den Endspurt zum Abschuss des SBS einläuten.
PS: @117471 etc. - Inspiriert durch Eure Anregungen konnte ich letztlich das Replikationsproblem lösen. Um aber späteren Lesern dieser Diskussionsrunde einen direkteren Zugang zu geben, hebe ich nur diesen Beitrag hervor, ohne Eure Beiträge dadurch schmälern zu wollen. Sie enthalten wichtige Überlegungen im Gesamtkontext.
Hallo,
mich würde mal interessieren, wie sich Samba als DC macht. Taugt das, um Gruppenrichtlinien mit den offiziellen Microsoft-Konsolentools zu formulieren?
Was mich auch abhält ist, dass ich irgendwie immer mehr DNS-Server in Betrieb habe:
Mit dem Samba-DC käme dann die nächste Komplexität hinzu. Zumal DHCP auf der pfSense bleiben soll.
Gruß,
Jörg
mich würde mal interessieren, wie sich Samba als DC macht. Taugt das, um Gruppenrichtlinien mit den offiziellen Microsoft-Konsolentools zu formulieren?
Was mich auch abhält ist, dass ich irgendwie immer mehr DNS-Server in Betrieb habe:
- die FRITZ!Box für 192.168.178.0/24 bzw. FRITZ!Box
- die pfSense für die Zone vom LAN und vom DMZ
- der piHole, der die entweder Quad9 oder den passenden lokalen DNS als Forwarder benutzt
Mit dem Samba-DC käme dann die nächste Komplexität hinzu. Zumal DHCP auf der pfSense bleiben soll.
Gruß,
Jörg
@HansDampf06:
Ein kleiner Hinweis: Das Active Directory kennt die Trennung PDC und BDC nicht mehr. Im Active Directory gibt es nur gleichwertige DC (später kam noch der RODC dazu, aber das ist ne andere Sache). PDC und BDC gab es nur bis NT 4.0.
Ein kleiner Hinweis: Das Active Directory kennt die Trennung PDC und BDC nicht mehr. Im Active Directory gibt es nur gleichwertige DC (später kam noch der RODC dazu, aber das ist ne andere Sache). PDC und BDC gab es nur bis NT 4.0.
@tikayevent: Das ist völlig richtig! Aber die alten Kürzel haben in der (zwischenmenschlichen) Kommunikation den unschlagbaren Vorteil, dass nach wie vor für alle Beteiligten sofort klar ist, welcher DC die FSMO-Aufgabe hat und wer nur Mitspieler ist. Ansonsten ist eine Unterscheidung freilich belanglos, weil die DC's nach außen (Clients etc.) hin völlig gleichwertig sind.
Zitat von @117471:
... interessieren, wie sich Samba als DC macht. Taugt das, um Gruppenrichtlinien mit den offiziellen Microsoft-Konsolentools zu formulieren?
... interessieren, wie sich Samba als DC macht. Taugt das, um Gruppenrichtlinien mit den offiziellen Microsoft-Konsolentools zu formulieren?
Das konnte ich bisher nicht testen, weil ich ja an der Replikation zwischen den DC's hängen geblieben bin. Aber es wird jetzt bei mir in den nächsten Schritten darum gehen, dass zu prüfen / zu testen. Immerhin sind GPO's einer der grundlegenden Vorteile, die ein Active Directory liefert und auf die ich vorerst nicht verzichten möchte.
Die Administration eines Samba-DC mit den RSA-Tools für Windows 8.1 sollte kein Problem darstellen. Hinsichtlich des DNS-Servers und der anderen AD-Tools hatte ich heute jedenfalls keine Problem feststellen können.
Was mich auch abhält ist, dass ich irgendwie immer mehr DNS-Server in Betrieb habe:
Mit dem Samba-DC käme dann die nächste Komplexität hinzu.
Mit dem Samba-DC käme dann die nächste Komplexität hinzu.
Vor diesem Problem stand ich auch einmal, insbesondere in Bezug auf den Router, der ebenfalls als DNS-/DHCP-Server fungieren kann. Aber meine klare Entscheidung dazu war: Es kann nur EINEN geben! So sind diese Funktionalitäten (bisher) ausschließlich auf dem SBS in Betrieb. Ist der SBS down, sind eben auch diese Funktionen down. Daher war ja mein längeres Bestreben, einen zweiten DC hinzuzufügen. Hinsichtlich des DHCP-Fallbacks ist das zwar nicht ganz so einfach auf einem weiteren DC, aber dazu hatte ich irgendwo mal ein scriptgesteuertes How-To gesehen.
Insgesamt fahre ich mit diesem Ansatz sorgenfrei, und zwar gerade weil meine interne Domäne bisher durchgehend störungsfrei läuft. Zudem ist die Administration / Pflege der Einstellungen auf das erforderliche Minimum reduziert. Mithin ist dieses Vorgehen meine Empfehlung.
Zumal DHCP auf der pfSense bleiben soll.
Das ist sicherlich in Bezug auf IPv6 ernsthaft überlegenswert. Andererseits ist ein DHCP, der zugleich DNS-Einträge anpassen kann/darf auch nicht von der Hand zu weisen. Letzteres war für mich bisher das ausschlaggebende Argument.
Zitat von @HansDampf06:
Da es aber eine produktive Umgebung ist, müsste die finale Umstellung letztlich doch für alle Member-Server und -Clients in einem Rutsch erfolgen? Das schließt aber nicht nur deren Abmelden bei der alten und das Anmelden bei der neuen Domäne ein, sondern erfordert zugleich solche Dinge wie SPN's im neuen AD nachtragen und keytab in der jeweiligen Serveranwendung neu erstellen. Das könnte vom reinen Zeitaufwand her schnell mehr als einen Tag Downtime bedeuten.
Da es aber eine produktive Umgebung ist, müsste die finale Umstellung letztlich doch für alle Member-Server und -Clients in einem Rutsch erfolgen? Das schließt aber nicht nur deren Abmelden bei der alten und das Anmelden bei der neuen Domäne ein, sondern erfordert zugleich solche Dinge wie SPN's im neuen AD nachtragen und keytab in der jeweiligen Serveranwendung neu erstellen. Das könnte vom reinen Zeitaufwand her schnell mehr als einen Tag Downtime bedeuten.
Alles in einem Rutsch wäre natürlich prima.
Ich habe hier auch noch einen Fall wo eine Kombination läuft.
1/3 der PCs auf dem alten SBS 2011 (ohne Exchange) in AD Firma1 (firma1.local)
1/3 der PCs auf dem alten 2012r2 in AD Firma2 (firma2.local)
1/3 der PCs auf dem neuem AD Firma1+2 (ad.firma1.de)
Zuerst Vertrauensstellungen erstellen, dann die Server und dann die PCs Gruppenweise.
Einziges Problem ist, dass der SBS so 1-2 mal pro Monat die Vertrauensstellungen wegwirft und man sie neu erstellen muss.
Stefan
und wo hängt es, dass du die nicht komplett noch umziehen kannst?
Meinst Du mich?
Das Übliche. Der Kunde kann sich nicht einigen ob der Exchange zu Microsoft soll oder inhouse bleiben soll, personelle Fluktuation, wechselnde Zuständigkeiten, hausinterne Umzüge, Zusammenschluss Firma1+2, und es gibt ja immer wichtigeres zu tun
Stefan
Das Übliche. Der Kunde kann sich nicht einigen ob der Exchange zu Microsoft soll oder inhouse bleiben soll, personelle Fluktuation, wechselnde Zuständigkeiten, hausinterne Umzüge, Zusammenschluss Firma1+2, und es gibt ja immer wichtigeres zu tun
Stefan
Startest du das einfach mal so "blind"? 
Wie groß wäre die Hausnummer denn?
Wie groß wäre die Hausnummer denn?
Nö
Man könnte das ohne Probleme an einem WE fertig machen, aber ich darf nicht....
Wie groß wäre die Hausnummer denn?
Alles zusammen sind das nur 40 PCs.Man könnte das ohne Probleme an einem WE fertig machen, aber ich darf nicht....
Mhh...na gut ;)
Es ist unterhaltsam
Zitat von @HansDampf06:
@tikayevent: Das ist völlig richtig! Aber die alten Kürzel haben in der (zwischenmenschlichen) Kommunikation den unschlagbaren Vorteil, dass nach wie vor für alle Beteiligten sofort klar ist, welcher DC die FSMO-Aufgabe hat und wer nur Mitspieler ist.
@tikayevent: Das ist völlig richtig! Aber die alten Kürzel haben in der (zwischenmenschlichen) Kommunikation den unschlagbaren Vorteil, dass nach wie vor für alle Beteiligten sofort klar ist, welcher DC die FSMO-Aufgabe hat und wer nur Mitspieler ist.
Nein hat es nicht weil es faktisch falsch ist. Die FSMO Rollen können auch auf 5 Servern liegen und tun dies in (sehr) großen Umgebungen auch. Wenn mir einer was von PDC und BDC im AD erzählt hat er gleich nen Stempel weg, nach 20 Jahren sollte das falsche Wording abgelegt sein.
/Thomas
sorry Thomas, aber ich würde darauf tippen, dass auch Heute (2020.11) noch genug Berufsschulen Netzklassen unterrichten...(bspw...)
Okay, okay, okay ...!
PS: Aber wenn schon auf korrekte (Fach)Sprache Wert gelegt wird, dann gehört für mich ganz gewiss nicht das hippige Anglifizieren wie "Wording" dazu. Die deutsche Sprache hat treffende(re) Begriffe wie "Wortwahl", "Begriff", "Bezeichnung", "Kürzel", "Abkürzung", um nur eine kleine Auswahl in den Ring zu werfen. Erst recht ist "Wording" kein terminus technicus, der per se für sich einen eigenständigen sprachlichen Geltungsanspruch zu fordern vermag.
Nur mal so der Vollständgkeit halber und zum Nachdenken.
PS: Aber wenn schon auf korrekte (Fach)Sprache Wert gelegt wird, dann gehört für mich ganz gewiss nicht das hippige Anglifizieren wie "Wording" dazu. Die deutsche Sprache hat treffende(re) Begriffe wie "Wortwahl", "Begriff", "Bezeichnung", "Kürzel", "Abkürzung", um nur eine kleine Auswahl in den Ring zu werfen. Erst recht ist "Wording" kein terminus technicus, der per se für sich einen eigenständigen sprachlichen Geltungsanspruch zu fordern vermag.
Nur mal so der Vollständgkeit halber und zum Nachdenken.
Zitat von @falscher-sperrstatus:
sorry Thomas, aber ich würde darauf tippen, dass auch Heute (2020.11) noch genug Berufsschulen Netzklassen unterrichten...(bspw...)
sorry Thomas, aber ich würde darauf tippen, dass auch Heute (2020.11) noch genug Berufsschulen Netzklassen unterrichten...(bspw...)
Das Lehrer ihre Unterlagen ab und an mal aktualisieren sollten, es aber nicht machen, ist ja leider nichts neues.
/Thomas
Sprache lebt, mit deiner Kritik vermag ich wenig anzufangen. Aber falls ich mich beim nächsten Mal an deine Präferenzen erinnere werde ich darauf achten nur deutsches Wortgut zu verwenden.
/Thomas
Warum so aufgeregt? (Die deutsche) Sprache lebt - Ja, insbesondere von der Benutzung ihrer Vielfalt an Ausdrucksmöglichkeiten. Nein, wenn die Ausdrucksmöglichkeiten gar nicht benutzt werden. Und wer seine Sprache gar nicht benutzt, braucht sich auch nicht hinter "Sprache lebt" zu verstecken, weil das offenkundig nur ein vorgeschobenes Feigenblatt für gedankenloses / hippiges Anglifizieren ist.
Frei nach Friedrich, dem Großen: Verwende doch, was Du willst!
Am besten Du anglifizierst gleich alles, dann muss Du Dich mit der deutschen Sprache gar nicht herumplagen. Zudem würdest Du mächtig Eindruck schinden ... vielleicht bei anderen.
PS: Ich bin dann weg von diesem Nebenkriegsschauplatz.
Frei nach Friedrich, dem Großen: Verwende doch, was Du willst!
Am besten Du anglifizierst gleich alles, dann muss Du Dich mit der deutschen Sprache gar nicht herumplagen. Zudem würdest Du mächtig Eindruck schinden ... vielleicht bei anderen.
PS: Ich bin dann weg von diesem Nebenkriegsschauplatz.
Ich bin nicht aufgeregt, halte es nur für Unsinn.
/Thomas
PS: Ich bin dann weg von diesem Nebenkriegsschauplatz.
Dem schließe ich mich an./Thomas
Hallo,
...klingt "gewagt", da es sich ja offenbar um ein Produktivnetz handelt.
Nö. Wenn Du z.B. die Geräte auf der FRITZ!Box automatisiert verwalten möchtest und die dynamischen Hostnamen (...auch von den VPN-Clients) sauber vor- und rückwärts aufgelöst im DNS haben möchtest, setzt Du dich mit deiner Lösung bestmöglich auf die Nase.
Das funktioniert etwas anders:
Mit anderen Worten: Jeder trägt die Ressource ein, die er liefert.
Aber bastel' mal. Ich warte auf deine Erfahrungen
Gruß,
Jörg
Zitat von @HansDampf06:
Das konnte ich bisher nicht testen, weil ich ja an der Replikation zwischen den DC's hängen geblieben bin.
Aber es wird jetzt bei mir in den nächsten Schritten darum gehen, dass zu prüfen / zu testen.
Das konnte ich bisher nicht testen, weil ich ja an der Replikation zwischen den DC's hängen geblieben bin.
Aber es wird jetzt bei mir in den nächsten Schritten darum gehen, dass zu prüfen / zu testen.
...klingt "gewagt", da es sich ja offenbar um ein Produktivnetz handelt.
Aber meine klare Entscheidung dazu war: Es kann nur EINEN geben!
Nö. Wenn Du z.B. die Geräte auf der FRITZ!Box automatisiert verwalten möchtest und die dynamischen Hostnamen (...auch von den VPN-Clients) sauber vor- und rückwärts aufgelöst im DNS haben möchtest, setzt Du dich mit deiner Lösung bestmöglich auf die Nase.
Andererseits ist ein DHCP, der zugleich DNS-Einträge anpassen kann/darf
Das funktioniert etwas anders:
- Der Hostname wird vom Client eingetragen
- Die reverse Auflösung wird vom DHCP-Server eingetragen
Mit anderen Worten: Jeder trägt die Ressource ein, die er liefert.
Aber bastel' mal. Ich warte auf deine Erfahrungen
Gruß,
Jörg
