Cross forest Distribution Group list expansion
We have two forests in a 2-way trust. On each forest there's an Exchange 2016 Organization installed. On one forest a Distribution group has been created with users from both the forests, in ADUC we see the membership correctly for all the users. On the Exchange Console of that Forest opening the DG we can see only the "local" users and the SID for the remote one. Sending an email to the DG it only delivers to local forest's users. Why Exchange Server doesn't expand the DG membership as the ADUC does and deliver emails to all recipient ? Do we have to replicate remote Forest's Users as local contacts ? thanks
Cross-forest roaming user profiles
hello , currently we have a forest A where citrix VDI solution are implemented and users are configured (via GPOs) to use roaming user profiles and folder redirect which are all stored in a fileserver cluster. we are doing a crossforest migration to forest B using ADMT and native exchange scripts. the goal is we want a migrated user(forest B) to log on Remote desktop session host on old domain (forest A) and access their user profiles and folders which is still on fileserver on forest A. all users are migrated with sidhistory. i have configured GPOs in new forest to configure roaming profiles and folder redirections to point to the same location (fileserver in forest a) . also enabled policy allow cross-forest policy and roaming profiles. still when a migrated user logs in (forestB\user) i receive an error ,failed to locate roaming profile and local copy is used. how can we achieve this scenario , i though that because sid history is migrated ,that the migrated user will have the same permissions to access profile and folders as the source user is (forest A\user) apperciate your helpEWS integration from SfB client to Exchange during a cross forest migration
Summary During a cross forest migration, a single forest (source forest) is moved to a new single forest (target forest). The users and services (AD, Exchange, Skype for Business and SharePoint) are moved in different phases from the source forest to the target forest. The new services such as Exchange and SfB are already implemented in the target forest and can already be used for tests (function, migration). The existing SIP/E-Mail domain will be reused in the new environment. So the SfB migration cannot be done in phases but must be done in one step ("Big Bang"). Challenge EWS is used for the client-side integration of the SfB client into the Exchange mailbox. A functioning autodiscover is required for this. The SfB client only uses the autodiscover via DNS. This is only one mechanism of the available Autodiscover mechanisms that Outlook can use. This integration via EWS should ideally be maintained at any time during the migration. Since the Exchange mailboxes are phase-wise converted, the situation arises that the DNS entry (autodisocover.domain.de) does not always point to the correct mailbox. This means that if the user's mailbox is switched to the new environment and the Autodiscover DNS entry still points to the old environment, the Skype Client will also connect to the old mailbox. So a data loss of the Conversation History is pre-programmed with the later conversion of the Autodiscover entry. Considerations With the Exchange migration the TargetAddress (AD attribute) with reference to the old Exchange mailbox (source forest) is set in the target forest before the mailbox migration. The TargetAddress can be understood as a forwarding mechanism. If the mailbox migration is successful and the CutOver is completed, the forwarding is removed from the target mailbox and is added to the source mailbox with a reference to the target mailbox. The assumption would be that the SfB client also makes an autodiscover request for the TargetAddress domain. This functionality seems to exist in the Outlook client. The advantage would be that we don't have to cut-over the Autodiscover centrally for everyone and the integration between Exchange and Skype remains intact for the whole migration. But we don’t see any behavior in the client that indicates that the SfB client honors the TargetAddress and performs an Autodiscover on the TargetAddress domain. Source: https://blogs.technet.microsoft.com/mhass/2010/06/16/autodiscover-using-targetaddress I traced a SfB client login with Charles for a user where the mailbox was already moved. But I see just messages via EWS that indicate a quite normal connection to the old mailbox. I would expect some redirect / 302 messages that redirect to the target forest. I read that this mechanism is also used in exchange hybrid scenarios where the mailbox is hosted in O365. We already opened a premier case but this was not very helpful until now. So the idea was if somebody from the community could help. Regards, Paul
