Gerber

Nein tatsächlich reicht das Recht auf die Anwendungsgruppe aus.

Wie genau spiegelt sich denn der Fehler wieder?
Kommt die Anmeldung und es wird versucht sich anzumelden oder was passiert?

Ich bin mir nicht sicher ob noch eine RBAC Rolle in dem Fall (wenn du Azure Active Directory in der AVD Umgebung zum joinen nutzt) auf den Session Host direkt vergeben werden muss, damit sich die User an den VMs anmelden können.
Dies ist z.B. notwendig, wenn du normale VMs in Azure Active Directory integrierst und sich Azure AD Benutzer auf diesen anmelden wollen. Hierzu wird definitiv noch eine RBAC Rolle benötigt...
 
- Du nutzt denke ich kein FSLOGIX für die Profile?
 
 
EDIT:

Du musst die RBAC ROlle wie gedacht zuweisen, damit sich die Benutzer bei Azure Active Directory AVD Umgebungen an den Session Hosts anmelden können:
 
 
 

Moin zusammen,
 
ein Kunde sucht ein Outlook Add in, mit dem er sich die Public Folder Kalendereinträge erinnern lassen kann.
Gangl bietet eine Server Lösung für Exchange OnPremise Server an, allerdings ist dieser Kunde in M365.
 
 
Kennt jemand ein einfaches Outlook Add In welches dies abbilden kann (natürlich auch kostenpflichtig)?
 
Danke im Voraus.
 
P.S. ein eigenes Postfach als zweites einbinden ist nicht gewünscht.
 
Grüße
Phil
Nachtrag:

Es gibt auch eine Arbeitsplatz Variante von Gangl:
 
Erinnerungen aus Öffentlichen Ordnern für Outlook (gangl.de)

Danke an alle für die Hilfe.

Folgender Thread hat bei meinem Problem ebenfalls geholfen.
Der gMSA Account habe ich per Powershell erstellt und für das Setup genutzt. Danach hat alles wie gewohnt funktioniert:
 
Azure AD Connect Installation schlägt fehl - MS Azure Forum - MCSEboard.de
 
Kurze Zusammenfassung:
 
1.
RootKey überprüfen. Falls nicht vorhanden erstellen 
Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)  
2.
gMSA Account erstellen:
 
# Computername $ServerAADc = ‚NetBIOS name of Azure AD Connect Server‘ # Create the Key New-ADServiceAccount -Name ‚_gMSA-AADC‘ -PrincipalsAllowedToRetrieveManagedPassword (‚{0}$‘ -f $ServerAADc) -DNSHostName (‚{0}.{1}‘ -f $ServerAADc, (Get-ADDomain).DNSRoot)  
3.
Account aktivieren und testen:
 
# Install Service account on AAD Connect server Install-ADServiceAccount -Identity _gMSA-AADC$ # Test Service Account and get account password Test-ADServiceAccount -Identity _gMSA-AADC$ Response = True  
4. Im Setup den gMSA Account nutzten.
 
Grüße
Phil

Du hast ein UPN hinzugefügt, richtig?

Dann lasse doch einfach die Einstellung auf "firma.local" und später bei der Überprüfung nimmst du den Haken raus, damit Azure AD Sync nicht meckert.
Die UPNs weißt du den Usern zu und fertig.
 
Edit:

den haken rausnehmen, bei der Überprüfung der Domains im AD Sync gegen Azure. Dort wird dir dann dein "firma.gv.at" korrekt und überprüft angezeigt.

Grüße
Phil

Moin zusammen,
 
Migration ist nun durchgelaufen.

Folgendes habe ich durchgeführt:

1.) Public Folder welche eine fehlerhafte ACL hatten (Laut MS) nochmals über die Exchange Shell neu angelegt und die gleichen Berechtigungen drauf verteilt.
 
2.) Job nochmals komplett beendet und mit dem Befehl "-AprovedSkippedItems" die fehlerhaften Elemente genehmigt
 
3.) Job wieder gestartet
 
4.) Sync lief danach durch.
 
##################
 
Vor dem abschließen des Batch musste ich nochmals die Übersprungenen Elemente genehmigen.

##################
 
Grüße
Phil

Gelöst:
 
zu 1.) Es wird direkt der Broker per Farmname angesprochen, welcher anhand der Sammlung die Sessions verteilt
Registry Eintrag muss für ältere Systeme gesetzt werden.
 
zu 2.) GPO ist nicht mehr notwendig. Hier hat es mir im Gegenteil Probleme gemacht.
 
Ein Problem hatte ich noch mit dem Reg Key in Verbindung mit dem Farmname. Im Server Manager hieß die Farm "RDS-Farm", allerdings hieß diese tatsächlich RDS_Farm.
 
Grüße
Phil

Kurzes EDIT:

Es gibt über die Webiste -> Websiteinformationen -> Alle Websiteninformationen anzeigen -> Speichermetriken die Möglichkeit die Sites, bzw. Dokumente der Sites zu browsen und nachzusehen, was genau den Speicher in der Site beantspruch...
 
 

Hallo zusammen,
 
ein kurzes Edit von meiner Seite:
 
ich habe es nun soweit mit der Hybrid Bereitstellung hinbekommen.
Über folgende Probleme bin ich gestoßen + Lösung:
 
1.)
Ich konnte von On Premise keine Mails nach O365 senden. Meine IP sei wohl auf einer Blacklist gestanden was falsch war.
Über das Portal von Microsoft hat es sogar bestätigt, dass meine IP Adresse nicht gebannt ist und trotzdem hat es nicht funktioniert.
 
Nach eintragen meiner Public IP bei den erlaubten Adressen unter dem Punkt "Schutz" sind die Mails sauber über den Connector in O365 angenommen worden.
 
2.)
Mails von O365 nach On Premise sind nicht angekommen. Die Connector Prüfung hat bereits fehlgeschlagen, dass keine Verbindung zum Remoteserver aufgebaut werden kann.
 
Ich habe unzählige Tests mit dem Remote Analyze Tool durchgeführt, welche alle erfolgreich waren.
Was sehr seltsam war:
Ich habe im Outbound Connector in O365 die Public IP vom Anschluss anstelle dem DNS Namen eingesetzt. Auch hier konnte keine Verbindung hergestellt werden.
 
Heute, ein Tag später genau das gleiche. Zum Test habe ich nochmals die IP Adresse eingesetzt und versucht den COnnector mit verschiedensten TLS Konfigurationen ans laufen zu bekommen. Siehe da, der Connector baut die Verbindung korrekt auf und kann eine Test E-mail an den lokalen Exchange versenden.
 
Nochmals den Namen eingesetzt und nun bekomme ich auch die Fehlermeldung, dass der Name komplett falsch von den Microsoft Nameservern aufgelöst wird.
Der MX Record ist bereits 3 Tage gesetzt und über MXtoolbox und weitere Dienste auch sauber auflösbar.

Warum auch immer Microsoft noch die alte IP auflöst und warum es ein Tag zuvor nicht mit der Public IP geklappt hat **keine Ahnung**
 
E-Mail von O365 nach On Premise funktioniert also.... 
 
3.)
Nicht alle Kalender können angezeigt / abgerufen werden.
 
Hier habe ich Probleme bei den Postfächern, welche vor der Hybridbereitstellung bereits in der Cloud waren und nicht neu erstellt oder migriert wurden.
Auf alle anderen Postfächer welche ich nach dem Wizard neu erstellt oder in die CLoud verschoben habe, dessen Kalender kann ich korrekt aufrufen.
 
Erstelle ich allerdings direkt ein O365 Postfach über die Lokale On Premise Konsole, dann kann ich den Kalender nicht öffnen.
 
Nochmal eine neue Erkenntnis hierzu:
Wenn ich über den PlanungsAssistent ein Termin erstelle und ein Benutzer aus der Cloud hinzufüge, dann wird der Kalender vom Cloud Postfach korrekt abgerufen und angezeigt ob Frei oder Gebucht ist.

Wird allerdings versucht den Kalender über OWA zu öffnen, dann kommt die Fehlermeldung, dass dieser nicht geöffnet werden kann.
 
Ich habe nun zum Test mal noch ein Outlook Profil angelegt und dort versucht die Kalender zu öffnen.
Funktioniert über Outlook problemlos. Nur über OWA gibt es die Probleme.
 
 
4.) 
Migration von den Postfächern nach O365 funktioniert nun ebenfalls.
 
------
 
Zum Test werde ich nun nochmal mit den Kalendern experimentieren. Ob dies nun ohne Probleme funktioniert.
Ebenfalls werde ich nochmals von der Modernen Hybrid Installation auf die Klassische wechseln, welche eingehende Verbindungen benötigt.
 
####
 
Eventuell kann mir ja jemand zum Punkt 3 noch etwas sagen und hatte ähnliche Probleme.
 
Danke euch.
 
 
Grüße
Phil
 

Guten Morgen zusammen,
 
genau.
Ich wollte nur zuerst die Funktionen mit der Hosts Datei antesten, bevor ich die DNS Einstellungen komplett für alle Clients umstelle.
 
Ebenfalls ist momentan auf dem alten Terminalserver noch Outlook 2010 im Einsatz. Die Version: 14.0.7237.5000 und ist somit mit dem Exchange 2016 kompatibel.
Bedeutet ich werde nächste Woche die DNS Einstellung auf den neuen Zeigen lassen.
 
 
Ehm habe ich mir ehrlich gesagt nicht wirklich Gedanken gemacht. Ich dachte wenn ich schon am migrieren bin ziehe ich den Server gleich auf Exchange 2019 hoch.
 
Es ist kein Proxy bei diesem Benutzer im Spiel.
 
Wie es das Gesetzt manchmal so will funktioniert heute auch unter dem Admin Profil das Autodiscover perfekt.
Ich habe über Nacht nichts verändert und nichts neu gestartet.
 
Manchmal darf man sich tatsächlich nicht alle Dinge hinterfragen .
 
Oo, werde ich mir doch mal noch genauer ansehen.
 
 
Ein Problem ist allerdings noch, dass ich nur Windows Server 2019 Lizenzen besitzen und somit eine dieser Lizenzen Downgraden müsste.
 
 
Grüße Phil