Kan kalender zien in Outlook, maar scheduling assistant niet

[Blokker_1999]

Om enkele problemen die we hebben met externe applicaties op te lossen werd ons aanbevolen om enkele roommailboxen reeds te verhuizen naar Exchange Online terwijl al de rest van onze mailboxen nog lokaal zit op Exchange 2016. Na de verhuis kan ik zonder probleem opnieuw de kalenders openen in mijn Outlook en zie ik of de ruimte wel of niet bezet is. Maar als ik dan een nieuwe meeting invite opstel en ik open in de scheduling assistant deze meeting room dan staat die rij gewoon gearceerd met de melding dat er geen free/busy informatie kon opgehaald worden.

Scheduling Assistant:


Zelfde room, kalender view


Ik heb de rechten nagekeken en via een security groep heb ik, en alle mailgebruikers, reviewer toegang tot deze kalender, anders zou ik ook niet in de kalenderview kunnen zien of de ruimte beschikbaar was. Ik heb deze ook al eens uit mijn cache gehaald, geprobeerd met een nieuw Outlook profiel en ook met de on-prem OWA krijg ik hetzelfde resultaat als ik daar de scheduling assistent open doe.

En alle zoekacties op het internet gaan er van uit dat je helemaal geen toegang zou hebben in een hybride omgeving, maar omdat ik de kalender wel kan zien lijkt dat dus niet het probleem te zijn. Iemand dit al tegengekomen?

[Brahiewahiewa]

Blokker_1999 schreef op woensdag 20 oktober 2021 @ 12:19:
... kan ik zonder probleem opnieuw de kalenders openen in mijn Outlook en zie ik of de ruimte wel of niet bezet is. Maar als ik dan een nieuwe meeting invite opstel en ik open in de scheduling assistant deze meeting room dan staat die rij gewoon gearceerd met de melding dat er geen free/busy informatie kon opgehaald worden...

De free/busy information wordt apart gegenereerd op de exchange home server (dus het is geen client process) en zal gerepliceerd moeten worden tussen jouw on premise Exchange servers en Exchange Online.
Zolang je daarvoor geen maatregelen neemt, zal deze foutmelding blijven terugkomen

[Blokker_1999]

Het probleem wordt eigenlijk nog vreemder. We hebben ook enkele user mailboxen in EXO zitten als test, en als ik die toe voeg dan heb ik wel free/busy informatie in de scheduling assistant van Outlook. 1 van die testmailboxen is op identieke wijze gemigreerd als waarmee ik de room mailboxen heb gemigreerd, dus daar kan het ook al niet aan liggen.

[Xelefim]

Hoe is de synchro tussen de 2? met azure ad connect? hybrid deployment? geeft deze geen fouten?

[Blokker_1999]

AAD connect inderdaad, geen fouten. En zoals eerder gemeld, de enkele usermailboxen die we als test gemigreerd hebben een tijd terug werken zonder problemen, de room mailboxen die nu een move hebben gehad tonen geen free/busy.

De exchangeconnectivitytester geeft ondertussen aan dat er een probleem zou zijn met het niet kunnen vinden vna de availabilityaddressspace, wat ook correct is daar deze niet is geconfigureerd in onze EXO omgeving. Maar dan moet ik opnieuw de vraag stellen: waarom heeft de ene mailbox wel een probleem en de andere niet?

Ik heb 1 van de rooms opnieuw on-prem gezet en van zodra dat voltooid was had ik weer free/busy op die room. Ik probeer deze nu via een migratie terug naar EXO te brengen ipv een moverequest, eens kijken of dat een verschil maakt, maar er lijkt daar weer iets mis te zijn met de configuratie voor migraties waardoor de batch niet aangemaakt kan worden. Hij kan geen verbinding leggen met de server, dus nu dat weer eerst troubleshooten.

[Xelefim]

doe eens get-mailbox 'mailbox name that works | select * & get-mailbox 'mailbox that doesn't work' | select *

zie je verschillen?

[akimosan]

https://techcommunity.mic...-moving-parts/ba-p/607704

Kijk of TargetApplicationUri en TargetAutodiscoverEpr goed staan ingesteld zowel in On-Premise als EXO
Dit was bij ons het probleem 2 jaar geleden bij overgang

Gebruik de Exchange cmdlet get-organizationrelationship en set-organizationrelationship desnoods om deze in te stellen.

get-organizationrelationship | select target* | fl

TargetApplicationUri : outlook.com
TargetSharingEpr :
TargetOwaURL : http://outlook.com/owa/<domainname>
TargetAutodiscoverEpr : https://autodiscover-s.ou...todiscover.svc/WSSecurity

[Blokker_1999]

akimosan schreef op dinsdag 2 november 2021 @ 08:52:
https://techcommunity.mic...-moving-parts/ba-p/607704

Kijk of TargetApplicationUri en TargetAutodiscoverEpr goed staan ingesteld zowel in On-Premise als EXO
Dit was bij ons het probleem 2 jaar geleden bij overgang

Gebruik de Exchange cmdlet get-organizationrelationship en set-organizationrelationship desnoods om deze in te stellen.

get-organizationrelationship | select target* | fl

TargetApplicationUri : outlook.com
TargetSharingEpr :
TargetOwaURL : http://outlook.com/owa/<domainname>
TargetAutodiscoverEpr : https://autodiscover-s.ou...todiscover.svc/WSSecurity

De TargetApplicationUri stond on-prem inderdaad foutief ingevuld, maar was alsnog slechts deel van de oplossing. Heb vandaag eindelijk van MS een support call gehad met iemand die de oplossing had. Er worden 2 domeinen gebruikt voor de externe adressen. zowel domain.onmicrosoft.com alsook domain.mail.onmicrosoft.com. Daarvan was in de organization sharing slechts 1 domein bekend, en natuurlijk hebben de gemigreerde mailboxen het andere domein gekregen. Hierdoor wist Exchange dus niet eens dat deze online opgehaald moest worden.

Nadat dat was aangepast kwam alles vrij snel tot leven.