AlbertMinrich

Hallo,

Exchange Server 2016, Outlook 2019.

Ich bin mit einem Domänenuser angemeldet, welcher ein Exchangepostfach hat. Beim ersten Outlookstart wird das Profil erstellt. Als Emailadresse wird automatisch die primäre SMTP-Adresse des Users verwendet. Man muss sich nur noch durchklicken.

Soweit alles gut.

Jetzt bin ich aber mit einem Domänenuser angemeldet, welcher KEIN Exchangepostfach hat. Ziel ist es, sich auf das Postfach eines anderes Users zu verbinden. Da der User keine primäre SMTP-Adresse hat, kommt ein Fenster (Willkommen bei Outlook), wo man eine Emailadresse eingeben kann. Gibt man hier die Adresse des anderen Users ein, wird man irgendwann nach den Anmeldedaten des anderen Users gefragt und dann passt das.

Gibt es eine Möglichkeit, die Emailadresse im "Willkommen bei Outlook"-Fenster vorzugeben?

Also z.B. sowas:

outlook.exe /CreateProfileWithMail:max.meier@meinefirma.de

Danke

Gruß

Martin

Geht wieder. Lösung: CB1 gelöscht und neu installiert 🙁.

Ziemlich unbefriedigende Lösung, aber wie gesagt … geht wieder.

Bei mir steht in der Zeile "full address" der Wert, den ich bei Sammlung in der Zeile "DNS-Name für den RD-Verbindungsbrokercluster" eingetragen habe. In unserem Fall ein RoundRobin DNS-Eintrag auf unsere beiden Connectionbroker.

Die Meldung: "Im Pool sind keine Computer vorhanden" hatte ich auch schon. Bei mir waren in der Sammlung unter Hostserver keine Sessionhost hinzugefügt oder alle hatten bei "Neue Verbindungen zulassen" den Wert Falsch.

Gruß

Martin

Hallo,

eine neu aufgesetzte RDS 2019 Farm.

2x Connectionbroker im HA-Modus (beide CB haben zusätzlich die Rolle "Web Access für Remotedesktop", einer hat noch zusätzlich die Rolle "RD-Lizenzierung")

mehrere Sessionhosts

Es gibt zwei DNS-Einträge (rds.domain.local) auf die Connectionbroker (RoundRobin).

Landen die Clients auf CB2 (CB, WebAccess), funktioniert die Anmeldung, Clients werden verteilt auf die Sessionhosts.

Landen sie auf CB1 (CB, WebAccess,RD-Lizenzierung) kommt noch vor der Anmeldemaske der Fehler "Remotedesktopverbindung. Ein interner Fehler ist aufgetreten."

Im Eventlog des Clients (Microsoft > Windows > TerminalServices-ClientActiveXCore > Microsoft-Windows-TerminalServerices-RDPClient/Operational) finden sich für jeden Fehlversuch 3 Einträge:

• 1024 Informationen: RDP ClientActiveX versucht, eine Verbindung mit dem Server (rds.domain.local) herzustellen
• 1105 Informationen: Die Mehrfachtransportverbindung wurde getrennt
• 1026 Informationen: Die Verbindung mit RDP ClientActiveX wurde getrennt (Ursache=4)

Im Eventlog des Connectionbrokers CB1 (Microsoft > Windows > RemoteDesktopServices-RdpCoreTS > Betriebsbereit) finden sich für jeden Fehlerversuch 15 Einträge:

• 131 Informationen: Vom Server wurde eine neue Verbindung "TCP" mit Client "IP-Adresse_des_Clients:53277" akzeptiert.
• 65 Informationen: Verbindung RDP-Tcp#10 wurde erstellt. 
• 72 Informationen: Aufgerufene Schnittstellenmethode: PrepareForAccept
• 72 Informationen: Aufgerufene Schnittstellenmethode: SendPolicyData
• 141 Informationen: PerfCounter-Sitzung mit Instanz-ID 10 gestartet
• 226 Warnung: RDP_TCP: Fehler beim Übergang von "StatePreparingX224CC" in Reaktion auf "Event_ERROR_SendingX224CC". (Fehlercode: 0x0)
• 72 Informationen: Aufgerufene Schnittstellenmethode: OnDisconnected(server initiated)
• 227 Fehler: 'Failed to get property Disconnect Reason' in CUMRDPConnection::GetDisconnectReason at 4828 err=[0x80070057]
• 227 Fehler: 'Failed to get property Disconnect Reason' in CUMRDPConnection::GetDisconnectReason at 4828 err=[0x80070057]
• 103 Informationen: Der Grund für die Trennung lautet: 0.
• 102 Informationen: Der Server hat die RDP-Hauptverbindung mit dem Client getrennt.
• 145 Informationen: Während der Verbindung hat der Server über 0 Sekunden keine Daten- oder Grafikaktualisierung gesendet (Idle1: 0, Idle2: 0).
• 148 Informationen: Der Kanal "rdpinpt" zwischen dem Server und dem Client wurde für Transporttunnel 0 geschlossen.
• 148 Informationen: Der Kanal "rdpcmd" zwischen dem Server und dem Client wurde für Transporttunnel 0 geschlossen.
• 148 Informationen: Der Kanal "rdplic" zwischen dem Server und dem Client wurde für Transporttunnel 0 geschlossen.

Ich weiß im Moment nicht weiter.

Danke

Gruß

Martin

Vielen Dank, das war sehr hilfreich. 

Benutzerkonfiguration > Administrative Vorlagen > Microsoft Outlook 2019 > Kontoeinstellungen > Exchange > Autoermittlung deaktivieren für "Anfangsüberprüfung der Office 365-AutoErmittlungs-URL ausschließen"

Gruß

Martin

Hallo,

bisher haben wir im Einsatz:

• Exchange 2016
• Outlook 2010 und Outlook 2016

Startet ein neuer User das erste mal sein Outlook (egal welches), wird per Autodiscover der Exchange gefunden. Soweit so gut.

In einer neuen Remotedesktopfarm wollen wir jetzt Outlook 2019 verwenden, mit dem gleichen Exchange Server. Startet der User sein Outlook, wird seine Mailadresse angezeigt und er kann auf Verbinden klicken. Als nächstes kommt ein Fenster mit "Kontotyp auswählen". Hier wähle ich Exchange.  Daraufhin erscheint ein Anmeldefenster für ein Microsoftkonto. Der User hat aber keins und selbst wenn, ich will nur mit dem lokalen Exchange verbunden werden und nicht mit Microsoft Online.

Verbiete ich dem Terminalserver den Zugriff aufs Internet, klappt das auch und der User kann normal arbeiten. Aber das prüft Outlook wohl jedesmal, ist die Internetverbindung wiederhergestellt und startet man Outlook, kommt wieder die Microsoftanmeldung.

Kann man das irgendwie verhindern?

Ich hab was von einem "Hybrid Agent" gelesen. Dieser setzt ein Azure AD Connect voraus. Letzteres haben wir vor kurzem eingerichtet. Ist das also die einzige Möglichkeit, der Hybrid Agent oder gibt's noch eine andere?

Danke

Gruß

Martin

Hallo,

nach weiteren Tests (und warten) habe ich festgestellt, dass der neue Standarddrucker nach einer gewissen Zeit doch automatisch aktiv wird. Das passt dann für uns, so oft wechselt der ja nicht.

Übrigens, die Windows-Verwaltung des Standarddruckers wird aktiv.

Gruß

Martin

Hallo,

wir haben eine Windows Server 2019 RDS-Farm (ohne Citrix).

Die Drucker werden per GPP mittels Zielgruppenadressierung gesetzt.

Ich breche es mal runter. Es gibt eine GPO, darin gibt es vier GPP-Drucker:

• DruckerA                         = zielgruppenadressiert für die Gruppe A
• DruckerA als Standard    = zielgruppenadressiert für die Gruppe A-Standard
• DruckerB                         = zielgruppenadressiert für die Gruppe B
• DruckerB als Standard    = zielgruppenadressiert für die Gruppe B-Standard

Ein User, der bisher in noch keiner der Gruppen war, wird aufgenommen in Gruppe A-Standard und Gruppe B.

Nach Anmeldung hat er die beiden Drucker drin, DruckerA ist Standard, also alles korrekt.

Jetzt tausche ich die Gruppen, User ist also nur noch in den Gruppen A und B-Standard.

Nach Neuanmeldung ist immer noch DruckerA Standard, also nicht korrekt.

Führe ich in der Usersession manuell ein "gpupdate /target:user" aus (egal ob mit oder ohne /force), wechselt der Standarddrucker, dann passt es. Aber wieso geht das nicht automatisch bei Anmeldung.

Die GPP's sind eingestellt auf Aktion "Aktualisieren". Verwende ich "Ersetzen" funktioniert es auch bei Anmeldung korrekt, will ich aber nicht, weil das die Anmeldezeit unnötig verlängert, auch wenn's nicht viel ist.

Lösche ich in der Usersession einen der beiden Drucker, egal welchen, funktioniert es auch bei der nächsten Anmeldung.

Wie kann ich Windows dazu bewegen, bei der Anmeldung die aktuellen Gruppenrichtlinieneinstellungen zu übernehmen oder was könnte sonst das Problem sein?

Danke

Gruß

Martin

Ok, dann hat es sich ja geklärt.

Danke und Gruß

Martin

vor 13 Minuten schrieb Nobbyaushb:

Und nein, meines Wissens musst du auch bei Exchange 2016 SA haben um Vmotion abzudecken - @lizenzdoc

Deshalb ja die Frage, ob sich das geändert hat. Wir hatten (und haben immer noch) Exchange 2010.

Hallo,

ich muss mal kurz zwischenfragen. Hat sich bezüglich Exchange 2016 was geändert, was Vmotion/SA betrifft? Wir haben einen Exchange 2010 Standard ohne SA und nutzen auch Vmotion/DRS.  Das wurde bei einem Microsoft-Lizenzaudit vor 2 Jahren nicht bemängelt. SQL (2012 Standard) ist klar, mit SA, haben wir auch so.

Danke

Martin

Um die UAC wirklich komplett zu deaktivieren, mach ich immer folgendes:

1. Systemsteuerung > Benutzenkontensteuerung > Schieberegler ganz nach unten

2. gpedit.msc > Computer Konfiguration > Windows-Einstellungen > Sicherheitseinstellungen > Lokale Richtlinien > Sicherheitsoptionen

Und hier alphabetisch sortieren und die obersten beiden Punkte:

- "Benutzerkontensteuerung: Administratorbestätigungsmodus für das integrierte Administratorkonto"

- "Benutzerkontensteuerung: Alle Administratoren im Administratorbestätigungsmodus ausführen"

deaktivieren

3. Reboot

Um zu prüfen, ob die UAC wirklich deaktiviert ist:

Taste [Windows] + [R] > cmd

"whoami /groups"

Wenn hier in der letzten Zeile in der Spalte SID die SID mit 12288 endet, ist UAC deaktiviert.

Endet sie mit einer vierstelligen Zahl, beginnend mit 8 (den Rest weiß ich jetzt Grad nicht), ist UAC aktiv.

Gruß

Martin

Danke für die Antworten.

Natürlich wollen wir von der IT-Abteilung es auch möglichst einfach halten.

Aber die Anforderungen aus den Fachabteilungen sind damit nicht immer vereinbar.

Und manchmal sticht Ober Unter.

Danke und Gruß

Martin

Bekommt man evtl. mit DFS eine etwas bessere Lösung hin?!

 

Nur mal so ein Gedanke:

 

- Ordner (separate Fileablage mit separaten Rechten) im DFS Stamm mit "einhängen" -> für die Nutzeransicht ändert sich nichts

 

DFS:

\\contoso.com\Fileablage\Einkauf -> physikalisch (\\Server1\Einkauf)

\\contoso.com\Fileablage\Einkauf\Leitung -> physikalisch (\\Server1\Leitung)

 

Ist nur eine Idee. 

Ja, DFS ist auch eine gute Idee.

Danke für alle Infos/Kommentare/Anregungen

Gruß

Martin

Nein wir meinen nicht das gleiche.

OK, danke für die Aufklärung.

Vielleicht fällt ja noch jemanden was ein, der etwas mitteilungsfreudiger ist.  ;)

Nein das ist nicht das gleiche. Und solange du den Unterschied nicht findest, wird's schwierig. ;)

Ich glaub, wir meinen schon das gleiche. Die geerbten Berechtigungen kann man nur entfernen, wenn man die Vererbung deaktiviert. Ich denke, da sind wir uns einig. Beim Deaktivieren der Vererbung kann man die bisher geerbten Berechtigungen übernehmen. Die effektiven Berechtigungen auf den Ordner sind dann erstmal genauso, wie vor der Deaktivierung. Nur, dass sie nicht mehr geerbt, sondern explizit gesetzt sind.

Falls du was anderes meinst, klär mich doch bitte auf.

Wieso soll man nicht? Entweder du entfernst die vererbbaren Berechtigungen oder du unterbrichst die Vererbung. Das sind zwei Möglichkeiten. Und die dritte hat dir Daniel genannt.

Um die vererbbaren Berechtigungen entfernen zu können, muss ich die Vererbung unterbrechen, das ist also das gleiche. Und wieso man das nicht soll, hab ich schon geschrieben:

"Man ändert oben die Berechtigungen und geht davon aus, dass das für alles darunter durchvererbt wird. Das irgendwo unten in der Ordnerstruktur die Vererbung ausgeschaltet wurde, sieht man ja auf den ersten Blick nicht."

Und man liest es immer wieder.

Z.B. hier

http://www.fileserver-tools.com/2012/08/windows-berechtigungen-optimal-setzen-2/   unter Punkt 6: " Die Vererbung zu unterbrechen ist ganz schlechter Stil, weswegen man das nur in ganz seltenen Ausnahmefällen machen sollte"

Aber es gibt wohl auch andere Meinungen.

Ich möchte hier gar keine Grundsatzdiskussion entfachen.

Vielen Dank für alle Antworten

Gruß

Martin

...nach Entfernen der vererbbaren Berechtigungen...

So haben wir es ja bisher gemacht. Aber, wie man immer wieder liest, soll man das ja nicht. Versteh ich ja auch. Man ändert oben die Berechtigungen und geht davon aus, dass das für alles darunter durchvererbt wird. Das irgendwo unten in der Ordnerstruktur die Vererbung ausgeschaltet wurde, sieht man ja auf den ersten Blick nicht. Außer man hat eine gute Doku oder entsprechende Tools.

Wenn unterhalb von Einkauf "Berechtigungen" nicht von dir verwaltet werden, was ist dann dein Problem? ;) Wer dort Berechtigungen anpassen will/muss, sollte von dir eine Einweisung erhalten, oder du stellst deine Ordnerstruktur so um, dass nur du Berechtigungen vergeben kannst, oder so dass es nicht notwendig ist, Berechtigungen anzupassen.

 

Bye

Norbert

 

PS: Reden wir hier von einer tatsächlichen Aufgabe, oder sind wir in Theorie und Schulungsaufgaben?

Die Berechtigungen werden auf jeden Fall von der IT-Abteilung gepflegt. Wenn man das die User machen lässt, das gibt nur Chaos.

Und ich geb dir ja recht, man sollte die Struktur von vornherein so aufbauen, dass danach keine Änderungen mehr notwendig sind. Bloss in der Praxis wird das nicht immer möglich sein.

Auf mein Beispiel bezogen, könnte ich natürlich auch den Ordner ObersteLeitung eine Ebene nach oben holen, dann gäbe es

\\Server01\Einkauf\Leitung

und

\\Server01\Einkauf\ObersteLeitung

Ist vielleicht die beste Lösung, aber vielleicht hat ja trotzdem noch jemand eine "schöne" technische Lösung, bei der der Ordner dort bleiben kann, wo er ist.

Es handelt sich übrigens nicht um eine Schulaufgabe, sondern um ein Problem aus der Praxis, vor dem wir immer wieder mal stehen. Bisher haben wir in diesen Fällen an dieser Stelle die Vererbung deaktiviert, aber das soll man ja nicht machen.

Gruß

Martin

Man vergibt auf dem oberen Ordner immer nur "Nur dieser Ordner"-Rechte. Das wird dann zwar ggf. etwas aufwändiger in Abhängigkeit deiner Struktur, aber man unterbricht nirgends die Vererbung.

Na ja, das bedeutet, ich (der Admin) muss die Berechtigungen für jeden Ordner unterhalb von \\Server01\Einkauf pflegen. Eigentlich stelle ich ja der Gruppe Einkauf den Ordner Einkauf zur Verfügung, damit sie sich darunter ihre eigene Ordnerstruktur einrichten kann. Wenn ich dann für jeden Ordner, der direkt unterhalb von Einkauf liegt, erst die Berechtigungen anpassen muss, ist das ja auch nicht Sinn der Sache.

Ausserdem bleibt das Problem letztendlich das gleiche.

Mal angenommen, ich mach es so wie du sagst, also  auf \\Server01\Einkauf\Leitung hat nur die Gruppe EinkaufLeitung Zugriff. Jetzt kommt nächste Woche die Anforderung, dass auf den Ordner \\Server01\Einkauf\Leitung\ObersteLeitung   die Gruppe EinkaufObersteLeitung Modify-Berechtigung haben soll, die Gruppe EinkaufLeitung keinen Zugriff.

Damit stehe ich wieder vor dem gleichen Problem. Zugegeben, ein recht konstruiertes Problem, aber kann man es lösen, rein technisch gesehen?

Danke

Martin 

Hallo,

in diversen NTFS-BestPractises liest man immer wieder, dass man die Vererbung möglichst nicht unterbrechen soll. Solange man in tieferliegenden Ordnern nur zusätzliche Berechtigungen vergibt, kein Problem, aber wie soll man Berechtigungen wegnehmen, ohne die Vererbung zu deaktivieren?

Beispiel:

Hallo,

ich hätte mal eine Frage zu richtigen Vorgehenseweise, wenn eine Gruppe Zugriff auf einen Ordner bekommen soll, der weiter unten in einer Ordnerstruktur liegt. Das wird jetzt etwas länger. Sorry, aber vielleicht mag es sich jemand antun.

Beispiel:

Es gibt die Freigabe \\Server1\Europa

Freigabeberechtigung: Jeder:Modify

NTFS-Berechtigung: Gruppe Europa:Modify

Unterhalb gibt es u.a. diese Unterordner:  \Deutschland\Bayern\Oberbayern\Muenchen

Jetzt bekommt die Gruppe Muenchen_M (deren Mitglieder nicht bereits in der Gruppe Europa enthalten sind) Modify-Rechte auf den Ordner Muenchen.

Das bringt den Mitgliedern der Gruppe erstmal noch nichts, weil sie mangels fehlender Rechte auf die übergeordneten Ordner nicht an den Ordner Muenchen rankommen.

Dafür gibts mehrere Lösungen: 

- die User bekommen eine Verknüpfung, die direkt nach Muenchen zeigt

- man hängt Muenchen in eine DFS-Struktur ein

- man arbeitet mit List-Berechtigungen bzw. List-Gruppen

Mir gehts jetzt mal um die Lösung mit List-Gruppen.

Wenn man nach NTFS BestPractises sucht, stößt man sehr schnell auf die Firma aikux mit den Produkten 8Man und Migraven.

Dazu gibts einige Videos. In diesem hier

http://www.migraven.com/videos/webinarvideos/best-practice-ntfs-berechtigungen/

ist ab 29:40 die Sache mit den List-Gruppen beschrieben.

Auf mein Beispiel bezogen würde das folgende Gruppen und Berechtigungen bedeuten:

 - auf Ebene \\Server01\Europa    bekommt eine Gruppe Europa_L List-Berechtigung, in dieser wird die Gruppe Muenchen_M Mitglied

 - auf Ebene \\Server01\Europa\Deutschland    bekommt eine Gruppe Deutschland_L List-Berechtigung, in dieser wird die Gruppe Muenchen_M Mitglied

 - auf Ebene \\Server01\Europa\Deutschland\Bayern    bekommt die Gruppe Muenchen_M List-Berechtigung

 - auf Ebene \\Server01\Europa\Deutschland\Bayern\Oberbayern    bekommt die Gruppe Muenchen_M List-Berechtigung

D.h., es wird nicht durchgängig mit List-Gruppen gearbeitet, sondern nur bis zur Hälfte der Ordnerstruktur. Begründet wird das mit einer gesunden Mischung aus der Anzahl der benötigten Gruppen und der notwendigen ACL-Änderungen, also eine Mischung aus diesen beiden Extremen:

Extrem 1 (viele Gruppen):

 - auf Ebene \\Server01\Europa    bekommt eine Gruppe Europa_L List-Berechtigung, in dieser wird die Gruppe Muenchen_M Mitglied

 - auf Ebene \\Server01\Europa\Deutschland    bekommt eine Gruppe Deutschland_L List-Berechtigung, in dieser wird die Gruppe Muenchen_M Mitglied

 - auf Ebene \\Server01\Europa\Deutschland\Bayern\Oberbayern    bekommt die Gruppe Muenchen_M List-Berechtigung

Ich hab irgendwann noch von einer anderen Variante gelesen (die nicht in dem Video vorkommt). Für jede Ebene wird eine List-Gruppe erstellt. Jede List-Gruppe wird in der direkt darüber liegenden List-Gruppe Mitglied, in der List-Gruppe der untersten Ebene schliesslich wird die eigentliche Berechtigungsgruppe Mitglied. Auf mein Beispiel bezogen:

- auf Ebene \\Server01\Europa    bekommt eine Gruppe Europa_L List-Berechtigung, in dieser wird die Gruppe Deutschland_L Mitglied 

- auf Ebene \\Server01\Europa\Deutschland    bekommt eine Gruppe Deutschland_L List-Berechtigung, in dieser wird die Gruppe Bayern_L Mitglied 

Wie macht ihr es?

Danke und Gruß

Martin

Hab´s gefunden. Die Stichwörter sind Pass-Through Session und NativeDriveMapping

http://support.citrix.com/article/CTX127872

Hallo,

wir haben eine 2008R2 Terminalserverfarm mit Citrix XenApp 6.5.

Jetzt wirds ein bissl verwirrend. Vorab: Es geht nicht darum, dass in der (ersten) Citrix-Terminalserversession die lokalen Laufwerke des Clients zur Verfügung stehen, sondern in der Terminalserversession wird eine zweite Citrix-Terminalserversession auf einen anderen Terminalserver (keiner aus der Farm, steht extern, nicht in unserem Verwaltungsbereich) aufgebaut und in dieser (zweiten) Session sollen die lokalen Laufwerke der ersten Session zur Verfügung stehen. Der Farm-Terminalserver ist in diesem Fall also der Client.

Also so:

Client >>> startet Session (ica) >>> Farm-TS >>> daraus eine zweite Session (ica) >>> externer TS (hier sollen die Laufwerke des Farm-TS zur Verfügung stehen).

Mein erster Gedanke war, dass am externen TS das Durchschleifen von Laufwerken verboten ist. Das ist aber nicht der Fall, denn wenn die erste Session per rdp aufgebaut wird, funktioniert es wie gewünscht, wird die erste per ica aufgebaut, funktionierts nicht.

Client > ica > Farm-TS > ica > ext. TS: keine Laufwerke von Farm-TS

Client > rdp > Farm-TS > ica > ext. TS: Laufwerke von Farm-TS vorhanden

Muß also an einer Citrix-GPO liegen, die bei der ersten Session greift. Bevor ich die jetzt mühsam zerpflücke, vielleicht weiß jemand, welche das sein könnte.

Ach ja. In der Citrix-GPO für die erste Session sind Clientlaufwerke verboten, aber nach meinem Verständnis ist das völlig unabhängig von der zweiten Session.

Danke und Gruß

Martin

Moin,

 

wie gesagt, ich habe keinen SQL Server bei der Hand. Aber auffindbar sollte das schon sein. Anders als ich es in Erinnerung hatte, wohl doch nicht in den einzelnen Steps, sondern für den Plan als ganzen.

 

[Maintenance Plan (Reporting and Logging Page)]

https://msdn.microsoft.com/en-us/library/ms180370%28v=sql.110%29.aspx

 

Gruß, Nils

Hurra. Den Button (Berichterstellung und Protokollierung) hab ich wohl bisher übersehen. :nene:

Und dort find ich auch mein Verzeichnis.

Danke für die Unterstüzung  :jau:

Gruß

Martin