AMiGA

Hallo zusammen, ist es möglich einen VCenter Update Manager mit mehreren VCenter-Instanzen zu nutzen? Hintergrund ist, dass wir demnächst eine zweite Umgebung mit einem eigenen VCenter (VCSA) aufbauen möchten (lizenzbedingt sind die VCenter-Umgebungen auf je drei ESX-Hosts beschränkt). Am liebsten würden wir auch für den neuen VCenter den bereits vorhandenen VUM nutzen. Es ist zwar möglich, den VUM mit dem Konfig-Tool (VMwareUpdateManagerUtility.exe) auf einen anderen VCenter "umzubiegen", aber eine Möglichkeit, tatsächlich mehrere VCenter anzugeben, haben wir noch nicht gefunden. Müssen wir die ganzen Patches tatsächlich alle doppelt herunterladen und verwalten? Gruß, AMiGA

Okay. Warum auch immer, aber kann man ja mit leben. Wir haben noch ein weiteres Problem: Bei den migrierten Raumpostfächern ist als Postfachstellvertretung mit Vollzugriff die AD-Gruppe "Exchange Organization Administrators" vorhanden. Diese können wir bei neu angelegten Räumen nicht hinzufügen. Im Dialog im GUI lassen sich ausschließlich Benutzer hinzufügen, AD-Sicherheitsgruppen werden weder aufgelistet noch lassen sie sich manuell hinzufügen. Wie kann man einer AD-Gruppe Vollzugriff erteilen? Add-MailboxFolderPermission -Identity "Raumpostfach:\Kalender" -User "Exchange Organization Administrators@domain.local" -AccessRights Owner schlägt fehl mit dem Hinweis, dass der Benutzer keine gültige SMTP-Adresse sei. Als Folge der fehlenden Berechtigung ist es uns nicht möglich, die Kalenderberechtigungen des Raumpostfaches in Outlook zu bearbeiten. Dies funktioniert nur, wenn wir als Stellvertretung mit Vollzugriff einen konkreten Benutzer hinzufügen, was aber eher unschön ist. Hat jemand vielleicht eine Idee, was wir falsch machen? Gruß, AMiGA

Hallo zusammen, wir haben kürzlich auf Exchange 2013 aktualisiert. In der alten Exchange-Umgebung (2007) haben wir diverse Raum-Postfächer angelegt. Bei der damaligen Konfiguration konnte bei der Anlage des Postfaches unter "Nachrichtenübermittlungseinstellungen" in den Übermittlungsoptionen eine Weiterleitungsadresse angegeben werden (die Raum-Reservierungen sollen alle an eine zentrale Adresse weitergeleitet werden). Bei der Neuanlage eines Raumes unter Exchange 2013 finden wir diese Option nicht mehr. Per "Get-Mailbox" in der Powershell kann man erkennen, dass bei dem alten Raum "DeliverToMailboxAndForward" aktiviert ist sowie unter "ForwardingAddress" eine interne Verteilergruppe als Ziel angegeben ist. Haben wir keine andere Möglichkeit, als diese beiden Werte bei jedem neuen Postfach per Powershell manuell zu setzen, um die gleiche Funktionalität zu erhalten? Wieso wurde diese Funktionalität entfernt? Gruß, AMiGA

Hallo zusammen, ich bin auf der Suche nach einem Werkzeug, welches mir NTFS-Berechtigungen visualisiert. Beispielsweise interessiert es mich, wo überall im Netzwerk Berechtigungen für eine bestimmte Gruppe vergeben sind. Oder aber auch welche Berechtigungen auf einem bestimmten Pfad vergeben sind. Bislang bin ich nur auf Docusnap gestoßen, was wohl u.a. diese Funktionalität bietet. Außerdem noch auf Parks Authorization Manager, welches aber nur ganz rudimentäre Funktionen bietet. Gibt es eventuell schlankere (günstigere) Tools, die ähnliche Features haben? Gruß, AMiGA

Da brauchst Du keine Bedenken haben. Sowohl Freigaben als auch installierte Drucker bleiben bestehen.

Ihr habt ja Recht bezüglich XP und in unser eigenen Domäne ist XP zum Glück auch abgelöst. Nichtsdestotrotz haben wir im Moment leider die akute Situation, dass wir die XP-Clients aus der anderen Domäne zumindest kurzfristig anbinden müssen (da ein anderer älterer RDS-Server abgelöst werden soll). Ich werde TLS1 mal testweise aktivieren. Ggf. auch die Authentifizierung auf Netzwerkebene testweise deaktivieren. Wobei es mir immer noch vollkommen schleierhaft ist, wieso dieses Problem nur mit Benutzern der anderen Domäne auftritt.

Hi blub, interpretiere ich das richtig, dass Du empfiehlst, auf dem Server TLS 1.0 auszuschalten? Meinst Du nur den Broker oder die RDS-Knoten oder beides? Ich würde allerdings nicht verstehen, wieso der Verbindungsaufbau einmal erfolgreich funktioniert und danach nie wieder. Erst recht würde ich nicht verstehen, wieso der Verbindungsaufbau mit domäneneigenen AD-Konten *immer* funktioniert (von XP aus). Gruß, AMiGA

Hallo, wir haben ein Problem mit Windows XP Clients und einer Windows Server 2012 R2 RDS-Umgebung (mit einem Broker und 2 konkreten Knoten). Ja, ich weiß, die XP Clients gehören abgeschafft, sie werden aber in einer Domäne genutzt, die an einem entfernten Standort ist und eine Vertrauensstellung zu unserer Domäne hat. Die XP Clients sind auf dem neusten Patchstand. Die RDP-Protokoll-Version ist 7.0. Den entsprechenden Registry-Fix von Microsoft, damit XP Clients trotz aktivierter Authentifizierung auf Netzwerkebene mit einem aktuellen RDS-Server kommunizieren können, haben wir durchgeführt (https://support.microsoft.com/de-de/kb/951608). Die Anbindung der XP Clients an sich funktioniert. Wenn wir uns mit einem Benutzer aus der eigenen Domäne am RDP Broker authentifizieren, funktioniert dies einwandfrei. Wenn wir uns nun mit einem Benutzer der entfernten Domäne authentifizieren, funktioniert dies exakt ein mal. Wenn die RDS-Sitzung beendet wird, kann keine erneute Verbindung aufgebaut werden. Nach der Kennworteingabe erscheint erneut der gleiche Dialog zur Kennworteingabe mit dem Hinweis, dass mit den angegebenen Anmeldedaten keine Verbindung aufgebaut werden konnte. Nach einem Neustart des XP-Clients funktioniert der Verbindungsaufbau wieder, aber erneut nur exakt einmal. Dieses Problem ist auf allen XP-Clients vorhanden und jederzeit reproduzierbar. In der Ereignisanzeige des Clients ist nichts erkennbar. In der Ereignisanzeige des RDP-Brokers ist lediglich zu erkennen, wie die Verbindung aufgebaut und sofort wieder abgebaut wird. Diese Events treten aber bei *jeder* Verbindung auf, auch bei erfolgreichen. In den konkreten RDS-Knoten ist in der Ereignisanzeige nichts zu erkennen. Hat jemand eine Idee, woran das noch liegen könnte? Gruß, AMiGA