phatair

Hallo zusammen, wenn ich bei uns Win 10 Clients aus der Domäne entferne, also am Client selber "Workgroup" auswähle, wird dieser Client in der AD nicht deaktiviert. Nach einem Reboot ist der Client zwar in der Workgroup, aber eben das AD Objekt weiterhin aktiv. Nun habe ich festgestellt, wenn ich beim entfernen des Clients den Domänen Administrator (als Test) angebe, wird der Client deaktiviert. Mache ich das aber mit unseren dedizierten Accounts, die auch für die Aufnahme von PCs in die Domäne berechtigt sind, wird der Client nicht deaktiviert. Das Problem war dann schnell gefunden, der User hatte nicht das Recht Computerobjekte zu löschen/deaktivieren. Er durfte nur Computer Objekte erstellen. Ich frage mich aber, warum konnte der Client trotzdem aus der AD entfernt und in die Workgroup aufgenommen werden. Hat jeder User das Recht ein Gerät aus der Domäne zu nehmen? Ist das per Default so? Grüße

Wir sprechen sowas von aneinander vorbei

Meinst du das ernst? Jede Software sollte grundsätzlich so funktionieren wie vom Hersteller definiert. Es geht doch nicht darum, wie ich mir das wünsche... Ein DC darf nicht einfach neu starten... das ist doch nicht nur mein persönlicher Anspruch... Deine Logik ist ja interessant. Danach kann jeder Hersteller machen was er will und einfach sagen, ist halt so. Bist a Depp Keine Software ist fehlerfrei, dass ist klar, aber hier muß man auch unterscheiden. Und ich bin auch seit knapp 20 Jahren it admin und habe die unterschiedlichsten Netzwerke administriert. Aus meiner Sicht hat sich die Qualität bei MS und den Updates in den letzten 2 Jahren deutlich verschlechtert. Es war früher sicherlich nicht top, aber besser. Aber die Aussagen mit dem testen und dem Anspruch an Software ist und bleibt für mich eine sehr fragwürdige und klingt eher nach Theorie als nach der Realität. Aber gut. Für mich ist hier Schluss mit der Diskussion. Das führt zu nichts und jeder hat so seine Ansichten.

Ähm... diesen Anspruch sollte man an eine Software haben dürfen. Komischerweise schaffen das auch viele Hersteller und MS hat das auch lange Zeit geschafft. Ich wußte nicht, dass "The SOFTWARE is provided AS-IS." bedeutet, dass die Software bei jedem Update nicht mehr wie gewünscht funktioniert. Wir kommen hier wohl nicht zusammen. Ich bleibe dabei, dass MS hier aktuell einen miesen Job macht und man das nicht einfach mit "ihr müsst halt Updates testen" abtun kann! Das ist vollkommen an der Realität vorbei argumentiert. Testen gehört grundsätzlich dazu, aber die Menge an fehlerhaften Updates von MS die grundlegende Features zerstören sind ein Unding und dürfen so einen Unternehmen nicht in der Regelmäßigkeit passieren. In der Theorie hat der Kunde natürlich die Wahl, in der Praxis aber nicht, da dafür die meisten Umgebungen viel zu sehr auf MS ausgerichtet und komplex sind. Vielleicht sorgt es dafür, dass zukünftige Projekte an andere Herstellern gehen und damit die Umgebung dann weniger MS lastig wird. Ich glaube aber eher nicht daran.

Sorry aber das ist vollkommen unrealistisch und klingt so als wäre jedes Unternehmen/IT Abteilung dazu in der Lage. Du lässt aber die Realität dabei komplett außen vor. Bei Windows clients mag das zum Teil noch zutreffen Server aber nur sehr schwer. Große Unternehmen können das machen, aber doch nicht jedes KMU. Nicht jedes Unternehmen hat eine Test Domäne und kann jedes System in einer Testumgebung abbilden. Das ist oft finanziell oder/und von der IT Mannschaft gar nicht zu bewältigen. Davon abgesehen sind in letzter Zeit die Microsoft Updates so miserabel, dass es dir passieren kann, dass in der Testumgebung alles sauber läuft und dann in der Produktivumgebung etwas schief geht. Außerdem sind das so gravierende Fehler, dass man sich fragt ob Microsoft überhaupt noch eine Qualitätssicherung hat. Admins sind keine beta tester und in einer einigermaßen normalen Windows IT Umgebung sollten solche Fehler nicht passieren, wenn Microsoft seinen Job machen würde.

Hi Thomas, bekanntes Problem, siehe hier (die einzelnen Artikel sind in dem Artikel verlinkt) ->https://www.borncity.com/blog/2022/01/14/microsoft-patchday-probleme-jan-2022-bugs-besttigt-updates-zurckgezogen/ Gibt noch mehr Probleme mit den Januar Updates. Macht langsam kein Spaß mehr Windows Server zu administrieren bzw. zu aktualisieren...

Hallo zusammen, Eine kurze Frage. Wir haben auf den meisten internen Servern den Internet Zugriff über unsere zentrale Firewall blockiert. Bei den Servern 2019 wird bei jeder Anmeldung der Browser geöffnet und versucht die Webseite www.msftconnecttest.com zu öffnen. Dies wird wohl durch NCSI ausgelöst, da Windows versucht zu prüfen ob eine Internetverbindung besteht. Nun könnten wir in der Firewall die benötigten urls freigegeben oder es gibt eine Möglichkeit NCSI per gpo zu deaktivieren. Hier schreibt Microsoft, dass dies nicht empfohlen wird. Gibt es irgendwelche Probleme, wenn man das deaktiviert? Es gibt zwar auch gpos um interne Server für NCSI zu nutzen, aber dazu müsste man ein einen Webserver laufen lassen um eine connection.txt bereitzustellen. Das ist mir die Funktion eigentlich nicht wert, da es ja nur um eine "online Prüfung" geht. Oder übersehe ich etwas? Vielen Dank. Gruß Steffen

Hier eine gute Übersicht von Tools, Infos und zB. bekannten IPs https://github.com/NCSC-NL/log4shell Eine Frage habe ich aber noch, da man darüber immer unterschiedliche Infos liest. Laut BSI ist ja die Lücke auch nutzbar, ohne das Schadcode nachgeladen wird. Bei uns haben so gut wie keine Server Internet Zugriff. Vor allem die Server in der DMZ haben das nicht. 2 Server in der DMZ nutzen tatsächlich Log4j. Einer konnte schon gepatched werden, der andere ist leider wichtig für den Unternehmensbetrieb und wurde so gut wie möglich isoliert. Er ist aber nicht per HTTP oder HTTPS von Extern erreichbar, was hoffentlich dazu führt, dass er noch nicht angegriffen wurde. Ist man etwas "sicherer" wenn die Server eben kein nachladen von Code ermöglichen oder spielt das tatsächlich keine Rolle? Ich lese immer wieder, dass über den String jndi:ldap:// der Angriff erfolgt und das würde doch bedeuten dass über den externen LDAP Server der Code nachgeladen werden muss.

Stimmt - gute Idee. Danke. Eine Frage habe ich doch noch. Ich würde gerne in den Profile Order, der in der VHDX enthalten ist, eine AD Sicherheitsgruppe in die ACL aufnehmen, damit die entsprechenden Admins beim mounten der VHDX im Problemfall auf das Profil zugreifen können. Im dem von dir verlinkten Powershell Script ist da ja problemlos möglich, aber wie mache ich das bei neuen VHDX Containern, die dann nicht über das Script erstellt werden? In den GPOs habe ich zwar die Richtlinie "Set access control for profile directory inside VHD" gefunden, aber meine Tests damit waren leider nicht erfolgreich. Hast du dazu noch eine Idee? Danke und Gruß

Ich mache noch mal einen neuen Beitrag, einfach damit es etwas übersichtlicher ist. ich hoffe das ist OK und es hilft vielleicht dem ein oder anderen der auch von Roaming Profiles zu FSLogix wechseln möchte. Ich habe den Fehler nun gefunden. Das Problem war, dass ich das Script mit einem User ausgeführt habe der lokal Adminrechte hatte (um überhaupt das VHDX mounten zu können) und auch auf das Target Ziel schreiben durfte. Er war aber nicht auf das Roaming Profile selber berechtigt und damit konnte er die Berechtigungen im VHDX nicht setzen. Das habe ich nun mal temporär angepasst und siehe da es läuft sauber durch. Einzig im Script Convert-Roaming-Profiles.ps1 musste ich an der Stelle wo die Berechtigungen gesetzt werden "Administrators" durch "Administratoren" ersetzen, da wir eine Deutsche Umgebung haben.

Hallo zusammen, soweit klappt die Migration nun erstmal. Das Script läuft sauber durch und ich habe es so angepasst, dass der Ordner für das FSLogix Profil USERNAME_SID ist und nicht mehr SID_USERNAME. Wenn ich mich dann allerdings am Test RDP Server anmelde, der für FSLogix konfiguriert ist, wird eine neue VHDX erstellt und meine migrierte in CORRUPTED_ umbenannt. Im FSLogix Log steht folgendes Creating new user profile disk (user's registry hive was missing) Laut Google ist das ein Problem mit der NTUser.dat, dass diese zum Beispiel nicht vorhanden ist oder wir noch eine andere Software/Lösung wie Roaming Profiles einsetzen die sich vorher die NTUser.dat geladen hat. Beides ist aber nicht mehr der Fall. Roaming Profiles habe ich in der GPO entfernt und ich habe in der VHDX nachgeschaut, dort ist die NTUser.dat vorhanden. Hat noch jemand eine Idee, woran das liegen kann? Kann bei der Migration innerhalb der VHDX die Berechtigung irgendwie zerschossen sein bzw. kann man das prüfen? Wenn ich die migrierte VHDX per FSLogix mounte kann ich erstmal nicht auf das Profil zugreifen. Ich muss die "Sicherheit" bearbeiten und mich als Besitzer eintragen. erst dann kann ich in das Profil schauen - ist das normal oder deutet das auf ein Berechtigungsproblem hin? EDIT: Gerade noch einen letzten Test gemacht 1. Neues sauberes FSLogix Profil durch FSLogix selber erstellen lassen. Diese VHDX mit dem FSLogix Tool gemounted. In das Profil kam ich erst rein, nach dem ich die typische Windows Meldung "sie benötigen Zugriff" bestätigt hatte. Damit war mein User zwar in der ACL Liste eingetragen aber das ist ja erstmal egal. Die Berechtigung war der eigentliche User, System und Admin 2. Das gleiche noch mal mit meinem migrierten FSLogix Container gemacht. Migrierte VHDX mit dem FSLogix Tool gemounted und versucht das Profil aufzurufen. Kam erstmal auch die typische Windows Meldung mit dem Zugriff. Die Meldung bestätigt und trotzdem kam ich nicht rein - es kam die Meldung, dass ich die Sicherheit bearbeiten muss. Also habe ich den Besitz übernommen und siehe da, es steht nichts in der ACL drin. Ich habe dann manuell SYSTEM mit Vollzugriff hinzugefügt und dann ging auch das anmelden mit diesem Container. Die Frage ist nun, wie bzw. wo läuft im Script mit der Berechtigung was schief. Oder liegt es am Ursprünglichen Roaming Profile...?

Ich antworte jetzt einfach auf mein Beitrag selber, da ich den Fehler gefunden habe. Es musste tatsächlich die komplette Hyper-V Plattform installiert werden und nicht nur die Verwaltungstools (so wie es ja auch in der Fehlermeldung steht). ich bin allerdings davon ausgegangen, dass das Scrpt das prüft (stand zumindest so in der Readme). Nach dem ich die hyper-v tools installiert habe, wurde auch das vhdx file erstellt. Nun muss ich morgen noch prüfen ob die Verwendung sauber funktioniert. Danke Jan für die Hilfe bis hier her.

also ich bin ratlos. ich habe jetzt auch das .V4 wieder angehängt. Trotzdem kommt der gleiche Fehler. Wenn ich folgende Befehl ausführe, erkennt er den User und auch die Version aber die SID und GUID kann er nicht auslesen New-MigrationObject -ProfilePath C:\temp\FSLOGIX\profiles\TEST-RDP.v4\ -Target C:\temp\FSLOGIX\ ProfilePath : C:\temp\FSLOGIX\profiles\TEST-RDP.v4\ Username : TEST-RDP Version : v4 UserSID : SID Not Found UserGUID : GUID Not Found Target : Cannot Copy Es gibt aber dieses AD Objekt. Ich habe die PS Konsole auch extra mit einem User gestartet, der Schreibzugriff auf die OU hat in der das Objekt liegt. Auch das hat nichts geholfen. Falls du noch eine Idee hast wäre ich dankbar, ansonsten würde ich die User wohl informieren, dass die Profile neu erstellt werden. die wichtigen Ordner haben wir ja sowieso umgeleitet. EDIT: Wenn ich Get-ADUser -identity test-rdp ausführe, dauert es etwas und dann erhalte ich die Meldung, dass der Server nicht verfügbar ist. Führe ich den Befehl auf einem der DCs aus, erhalte ich sofort die Infos. Ich habe unsere FW im Verdacht. EDIT2: also es lag tatsächlich an der FW. PS hatte den Port 9389 für die AD Abfrage genutzt und diesen hat unsere FW blockiert. Danach wurde der User gefunden. Nun kommt aber gleich der nächste Fehler. 10/21/2021 20:38:49 - Could not create or mount Profile Disk 10/21/2021 20:38:49 - Mit den Hyper-V-Verwaltungstools war kein Zugriff auf eine erwartete WMI-Klasse auf Computer "NB350" möglich. Dies kann darauf hinweisen, dass die Hyper-V-Plattform nicht auf dem Computer installiert ist oder dass die Version der Hyper-V-Plattform mit diesen Verwaltungstools nicht kompatibel ist. Ich habe auf meinem Win 10 20H2 einfach unter den "Windows Features aktivieren" die hyper-V-Verwaltungstools installiert. Muss ich hier noch weitere Module laden?

Hi Jan, "leider" gibt es einen AD User test-rdp und diesem gehört auch dieses Profil. Deshalb war ich so verwundert. Es sind auch alle notwendigen Module installiert (AD, HyperV und Pester). Das Profil liegt eben testweiter unter C:\temp auf meinem lokalen Notebook. Ich habe es aus dem UNC Pfad, wo die Profile normalerweise liegen, kopiert und extra die Endung .V4 gelöscht damit der Name sauber zugeordnet werden kann. Ich habe auch schon bei -Profilpath den abschließenden Backslash weggelassen. Ging trotzdem nicht. auch habe ich es mit meinem eigenen Profil getestet, auch dort kann er das AD Objekt nicht finden.

Danke Jan, ich hab mir das Script mal angeschaut und es beinhaltet ja schon eine Vorgabe für Roaming Profiles. Für den ersten Test habe ich mir mal ein Roaming Profile lokal kopiert und mit folgendem PS Befehl versucht das Profil zu migirieren Convert-RoamingProfile -ProfilePath "C:\temp\Test FSLOGIX\test-rdp\" -Target "C:\temp\Test FSLOGIX\" -VHDMaxSizeGB 5 -LogPath 'C:\temp\Test FSLOGIX\log.txt' Hier erhalte ich leider folgende Fehlermeldung im Log "Could not resolve to AD User. Cannot copy." Ich habe mir das Script mal angeschaut, leider bin ich kein Programmierer und so richtig verstehe ich nicht wie er versucht aus dem Pfad/Ordner den AD User zu erkennen. Kennst du vielleicht das Problem bzw. die Lösung? Danke und Gruß, Steffen

Hallo zusammen, wir setzen bei uns aktuell noch 2012R2 RDP Hosts zusammen mit Roaming Profiles ein. Die "temporären" lokalen Profile werden nach einer Abmeldung vom RDP Host gelöscht (per GPO so gesetzt). Nun stellen wir auf 2019 RDP Hosts um und wollen in diesem Zuge auch auf die FSLogix Container umstellen. Soweit ist alle konfiguriert und beim testen ist nun folgendes aufgefallen. Die Container lassen sich zwar per CLI und dem Befehl "frx.exe copy-profile -filename Profile_User.vhdx -username contoso\user -dynamic 1 -verbose" kopieren, aber dazu muss das lokale Profil auf dem RDP Server vorhanden und der User darf nicht angemeldet sein (Es wird wohl der Reg Key aus UserProfile gelesen/übernommen oder so was ähnliches). Nun kann man mit dem Parameter -profile-path= noch den Pfad zum Profil angeben. Dort habe ich dann den UNC Pfad zum Roaming Profile angegeben, aber hier habe ich immer die Fehlermeldung Formatting volume: \\?\Volume{d763ba77-a660-47d9-8e2d-fe2eb0257308}\ Copying profile for user S-1-5-21-602162358-1844237615-839522115-5229 to volume \\?\Volume{d763ba77-a660-47d9-8e2d-fe2eb0257308}\ Error copying profile (0x00000001): Unzulõssige Funktion. Wenn ich das Roaming Profile lokal in einem temporären Ordner kopiere und dann den Befehl ausführe erhalte ich den gleichen Fehler. Hat hier noch jemand eine Idee? Die bestehenden RDP Hosts per GPO so zu konfigurieren, dass das Profil trotz Roaming Profile lokal beim abmelden erhalten bleibt ist erstmal keine Lösung. Da würde ich die Profile auf den neuen Hosts einfach neu anlegen lassen, da wir die wichtigen Ordner wie Desktop, Dokumente usw. sowieso auf das Home Laufwerk umleiten. Danke und Gruß

In der Doku steht dazu nur das und ich bin mir nicht sicher ob ich es so richtig verstanden haben. Ich würde es so interpretieren, da "...When such expiration is detected, password is changed immediately and password expiration is set according to policy" steht. Aber es steht eben nicht explizit da, dass dies auch passiert wenn keine AD Anbindung vorhanden ist. Wie gesagt, einen Test machen wir noch, aber falls mir schon vorher jemand helfen kann habe ich nichts dagegen :) EDIT: Ich denke ich habe das falsch interpretiert. Es scheint eher darum zu gehen, wenn ein Admin Account mit einem längeren Passwort Zeitraum vorhanden ist, wie in den LAPS GPO "Passwort Settings" definiert.

Ich werde es zwar noch mal bei uns testen, aber vielleicht könnt ihr mir trotzdem noch mal auf die Sprünge helfen. Ich verstehe das jetzt so: - ich definiere einen Zeitpunkt, wann das lokale Passwort von der CSE geändert werden soll -> z.B. alter 30 Tage - die CSE generiert ein neues lokale Admin Passwort, wenn dieses Alter erreicht ist und versucht dieses dann in der AD zu speichern - Ist die Speicherung erfolgreich, wird es auf dem Client geändert Das würde für mich bedeuten, wenn z.B. ein Notebook außer Haus ist und die AD nicht erreicht werden kann, wird das Passwort auch nicht geändert. Auch wenn der Zeitpunkt laut Policy schon gegeben ist. Ist dafür die GPO "Do not allow password expiration time longer than required by policy" verantwortlich? Würde ich diese aktivieren, wird das Passwort gesetzt sobald der Zeitpunkt für die Passwort Änderung überschritten ist und es wird nicht geprüft ob die AD erreicht werden kann? Ich werde hier aus der Doku noch nicht ganz schlau. Vielen Dank.

Den Gedanken mit den Notebooks hatte ich auch. Ich hatte gehofft, dass die Geräte, die zu dem Zeitpunkt der geplanten Passwortänderung nicht das AD erreichen können, diese Änderung aufschieben bis sie wieder eine AD Verbindung haben und das neue Passwort übertragen können. Deiner Aussage entnehme ich - dem ist nicht so? :(

Danke Danke! Deinen Post habe ich mir schon vor 2 Jahren angeschaut und Anregungen geholt :) Ich habe auch ein paar sehr gute Beiträge über die AD Absicherung bei Frankysweb.de gefunden. Hier geht es auch um das einrichten von Tiering, PAWs und LAPS. Wenn wir nächste Woche unser AD Audit abgeschlossen haben, werde ich mich mal noch tiefer mit diesen Themen beschäftigen und diese dann bei uns umsetzen. Ein paar Fragen habe ich jetzt schon, aber wenn die nach dem AD Audit noch offen sind werde ich einen neun Thread dazu eröffnen. Danke für eure Hilfe.

Hi Nils, ok, dass klingt dann für mich schon schlüssiger :) Ich werde nach den beiden Schlagworten mal googlen. Die Trennung der Admin Accounts haben wir schon fast komplett durchgezogen. Was uns noch fehlt sind die PAWs. Demnächst haben wir erstmal ein AD Security Audit und da bin ich dann mal gespannt was noch so alles auf uns zukommt (ldap channel binding and ldap signing, usw). Aber das ist ein anderes Thema. Remoteunterstützung oder Telefon ist natürlich klar. Mir ging es vor allem um die grundsätzliche Idee und ob ich diese so wirklich richtig verstanden haben. Es kann natürlich schon dazu führen, dass der Support etwas in die länge gezogen wird und da stellt sich dann die Frage ob Aufwand - Nutzen wirklich so groß ist. Die Trennung, die der Nils erwähnt hat, klingt für mich im ersten Schritt auf jeden fall praxistauglicher :) Gruß, Steffen

Hallo zusammen, ich habe auf dem Born Blog einen interessanten Artikel gelesen, der mich etwas zum nachdenken gebracht hat. https://www.borncity.com/blog/2021/09/11/active-directory-vor-ransomware-attacken-schtzen/ Wir haben vor ein paar Jahren unsere Admin Accounts wie folgt aufgeteilt: - jeder Admin arbeitet an seinem Geräte mit einem normalen AD Account ohne erhöhte Rechte. - für Server Tätigkeiten hat jeder Admin einen eigenen Server Admin. Dieser wird per GPO auf die benötigten Server in die lokale Admin Gruppe eingetragen. So hat nicht jeder Admin auf alle Server zugriff. - für Client Tätigkeiten hat jeder Admin einen eignen Client Admin. Dieser wird ebenso per GPO auf die benötigten Clients in die lokale Admin Gruppe eingetragen. - der lokale Standard Admin auf den Servern ist deaktiviert und ein neuer mit geändertem Namen wurde erstellt. Jeder dieser lokalen Server Admin Accounts hat ein eigenes Passwort (aktuell noch ohne LAPS) Über das Thema hatten wir 2019 hier schon mal diskutiert :) Nun schlägt der Beitrag auf borncity.com ja unteranderem folgende Maßnahme vor: Erstens, muss das lokale Administratorkennwort auf jedem Endpunkt unterschiedlich sein. Microsoft offeriert hierfür eine kostenlose Lösung namens Local Administrator Password Solution (LAPS). Zweitens, sollten keine Domain-Konten in der Gruppe der lokalen Administratoren miteinander verwoben sein, um einen einfachen IT-Support zu ermöglichen. Punkt 1 mit LAPS wollen wir demnächst auch auf den Clients angehen und klingt für mich schlüssig (ich weiß, es gibt noch andere Tools mit denen man das machen kann). Punkt 2 ist für mich im Moment sehr sperrig und hier würde mich mal eure Meinung interessieren. Sicherheit geht meistens mit Komfort Verlust einher, aber das klingt für mich nicht ganz so praxistauglich. Das würde ja bedeuten, dass ich nur noch lokale Admins über LAPS erstelle und damit auch die administrative Tätigkeiten auf den Clients ausführen kann. Bin ich also beim User vor Ort und muss dort erhöhte Rechte anfordern, muss ich irgendwie and das LAPS kommen, sonst kann ich nichts tun. Wie handhabt ihr das bei euch? Ähnlich wie wir - mit getrennten Admin Accounts oder ganz anders? Würde mich interessieren. Vielleicht verstehe ich den obigen Vorschlag auch falsch oder habe einen Denkfehler :) Grüße!

Vielen Dank für eure Antworten. Der Hintergrund, warum wir nicht einfach immer beide Mail Adressen erstellen wollen, ist das unser Mail Gateway die AD Objekte einließt und dort die Attribute "mail und proxyAddresses" ausliest. Nur diese Adressen werden dann auch angenommen. Damit keine Mails von "ungenutzten" Mail Adressen angenommen werden, wollte ich das eben keine unnötigen Einträge in den proxyAddresses erstellt werden. Wird beim erstellen eines Accounts jeweils nachname@firma.de und m.nachname@firma.de erstellt, hätte ich 2 Adressen an die Mails gehen können und das Mail Gateway auch durchlässt. Ich kann aber das Attribute "proxyAddresses" nicht so einfach rausnehmen, da ich mir nicht sicher bin ob die von Exchange Hybrid angelegten Einträge dort vorhanden sein müssen bzw. es vielleicht Einträge gibt die wir durchlassen müssen. UPN, SamAccountName und Name wird ja schon vorher korrekt beim erstellen des AD Objekts gesetzt. Danach wird im Exchange über das bestehende AD Objekt das Mail Postfach erstellt. Lange Rede kurzer Sinn - ich passe die Einträge jetzt einfach manuell an. Ein Script oder ähnliches würde bei unserer Useranzahl keinen Sinn machen bzw. alles nur verkomplizieren. Praktisch wäre es gewesen, wenn der Exchange an Hand der Adressrichtlinie erkennt - oh die Adresse mit nachname@firma.de gibt es schon, also wende ich meine 2. Regel mit m.nachname@firma.de an. Aber halb so wild, wollte nur wissen ob das über die GUI geht oder ich einfach nur zu blöde bin :) Aber was mir beim tippen gerade auffällt. Wenn ich eine neue Adressrichtlinie erstelle, gilt die dann automatisch auch für bestehende Einträge oder nur für neu erstellte Mailboxen? Wenn es nur für neue Mailboxen gilt, wäre es ja ok.

Die Lösung hatte ich auch schon. In einer Mail Adressrichtlinie %s@firma.de %1g.%s@firma.de Dann werden aber für jeden neuen User 2 SMTP Einträge gemacht. Eben nachname@firma.de und m.nachname@firma.de Das möchte ich aber nicht. m.nachname@firma.de soll nur erstellt werden, wenn es nachname@firma.de schon gibt. Daran bin ich dann gescheitert.

Ok, dann lasse ich das mal lieber mit der Änderung :) Grundsätzlich auch kein Problem, das haben wir sogar im Moment so am laufen. Aber ich habe dann das Problem, wenn es die Mail Adresse schon mit dem Nachnamen gibt. Dann müsste er automatisch unsere 2. Lösung nehmen - erster Buchstabe vom Vornamen "." Nachname. Das habe ich über die Mail Adressrichtlinien noch nicht hinbekommen. Mit dem Alias hätte ich halt schon immer gleich die korrekte Standard Mail Adresse erhalten. Die Mail Adressrichtlinie müsste also erkennen - Nachname@firma.de gibt es schon , dann nehme ich m.nachname@firma.de Mit meiner jetzigen Lösung werden immer automatisch beide Adressen angelegt, dass ist natürlich nicht gewünscht :) Falls jemand eine Idee/Lösung hat, wäre ich dankbar.