Migrate Office 365 Groups to another tenant
How can I migrate an Office 365 group, including conversations and calendar, to a new tenant? I found how to migrate individuals using pst files. I found how to migrate from on premises to Office 365 using PowerShell. But nothing about Office 365 to Office 365 migration.Enterprise Vault Archive Data to O365
Hi Team, Can anyone please recommended tool (Microsoft tool/3rd Party) to migrate archive data from Enterprise Vault to O365. And do we have any data limit to migrate data to O365 per day? Just wondering what would be the timelines we consider to migrate per TB/GB data generally? Is it possible to perform EV migration without any tool (power shell scripts etc.? Any inputs will be appreciated. Regards,
Add domains in one tenant OR create individual tenants, that is the question
Hi guys, Pretty monumental decision needs to be made sooner rather than later, and I understand there are pros and cons to each. There are a total of 5 companies that are all part of the same family of companies, with one of the 5 companies being the mothership/holding company. To facilitate collaboration (Teams) I've initially thought that creating everyone inside of one tenant is the better answer. However, if these companies, as they grow, institute their own policies for things, would it make more sense to break them out now into their own tenant? I'm also thinking of branding situations in Azure AD and internal company communications may be better achieved with individual tenants, but would collaboration and granular permissions suffer as a result? Want to make this transition from G Suite to Office 365 a great move; one that everyone is glad happened and not one that is regretted. Any advice, best practices, etc. are welcome and appreciated. Thank you friends!
Office 365 Usercredentials are cached
We migrated our data from one tenant to another and a lot of the local user profiles still caches the old tenant data. We found that out because they had a lot of problems with the Teams client in connection with Outlook. Sent out Teams meeting invitations but weren't able to join the meetings... And we also figured out that if we are using this command: dsregcmd /status and the "Work Account 1" is still using the old Tenant (Tenant name, Tenant ID). So the user has to disconnect here manually. But is there a way to do it via Powershell? Or is there any other way to do it remotely for all users? Thanks in advance
Users Office 365 Outlook Crashing - Hyper-V with a VM RDS Server running on Server 2019 RDS
We have a brand new Dell R7515 with a new AMD EPYC Processer. The OS is Windows Server 2019 Hyper-V with a VM RDS Server running on Server 2019 Standard. We decided to go with a shared license Office Pro Plus installed on the RDS Server. Each user is licensed in O365 with an MS 365 Apps for Enterprise License. There was nothing special configured about each user's Outlook except Cached Mode was enabled since employees are using O365 Groups. Shortly after cutting over users, we found that some employees were experiencing crashes when sending emails outbound. The crashes appear to be completely random, unrepeatable and occur only a few times a day. The only consistent theme was 98% of the cases; the employee was hitting send right before the crash. Event Log Errors: Faulting application name: OUTLOOK.EXE, version: 16.0.13328.20356, time stamp: 0x5fa4af94 Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000 Exception code: 0xc0000005 Fault offset: 0xff00ffff Faulting process id: 0x39c0 Faulting application start time: 0x01d6bd0373b5916e Faulting application path: C:\Program Files (x86)\Microsoft Office\root\Office16\OUTLOOK.EXE Faulting module path: unknown Report Id: 1a3e6b0a-890d-4b30-b12f-1474c0ad8dc5 Faulting package full name: Faulting package-relative application ID: -------------------------------------------------------------------------------------------------------------------------------- Faulting application name: OUTLOOK.EXE, version: 16.0.13328.20292, time stamp: 0x5f976a62 Faulting module name: mso20win32client.dll, version: 0.0.0.0, time stamp: 0x5f925668 Exception code: 0xc0000005 Fault offset: 0x0005c7d4 Faulting process id: 0x6a70 Faulting application start time: 0x01d6bc4271fa08f9 Faulting application path: C:\Program Files (x86)\Microsoft Office\root\Office16\OUTLOOK.EXE Faulting module path: C:\Program Files (x86)\Common Files\Microsoft Shared\Office16\mso20win32client.dll Report Id: b68ac5e5-621c-435d-92cb-182d0771aa6e Faulting package full name: Faulting package-relative application ID: Steps Taken to Troubleshoot: Complete Reinstall ProPlus 64-Bit Complete Uninstall ProPlus 64-Bit Complete Install ProPlus 32-Bit Rolled back the version of Office using officec2rclient.exe /update user updatetoversion=16.0.12827.20470 Complete Uninstall of all Office and Reinstall of 32-Bit Disabled Hardware Acceleration Disabled Add-Ins Sfc /scannow dism online cleanup-image restorehealth Offline Chkdsk repair Brand new build of Server 2019 RDS Server with new 32-Bit Office install Host Firmware Updates Likely more that I cannot think of I attached ProcMon to Outlook.exe to monitor for System.Threading.ThreadAbortException or System.AccessViolationException. Today we experienced a crash at 9:01. Here were the exceptions recorded. [09:01:58] Exception: mailto:E06D7363.?AV?$windows_exception_impl@$0A@@@ [09:01:58] Exception: E06D7363.?AVOException@@ [09:01:58] Exception: E06D7363.?AVOException@@ [09:01:59] Exception: E06D7363.?AVOException@@ [09:01:59] Exception: 40080201 [09:01:59] Exception: 40080201 [09:01:59] Exception: 40080201 [09:01:59] Exception: 40080201 [09:01:59] Exception: 40080201 [09:01:59] Exception: mailto:E06D7363.?AVJson_exception@Json@Mso@@ [09:01:59] Exception: 40080201 CLR Version: vv4.0.30319 [09:02:00] Exception: E0434F4D.System.FormatException ("Input string was not in a correct format.") [13:57:27] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.") [13:57:27] Dump 1 initiated: C:\tools\OUTLOOK.EXE_201124_135727.dmp [13:57:29] Dump 1 writing: Estimated dump file size is 1317 MB.Why is RetentionHoldEnabled set to true during hybrid migration?
I noticed that my retention policies weren't being applied after migrating from Exchange 2010 to Office 365. I found this article indicating RetentionHoldEnabled is set to true during the migration and it needs to be disabled for your retention policies to function. What is the reason for this? Is there any issue with disabling this on all of the migrated mailboxes? https://support.microsoft.com/en-us/help/3194755/retention-policy-no-longer-works-after-a-mailbox-is-moved-from-the-on
Cutover migration with already setup Azure AD and SSO
Hi All, We are looking at doing a cutover migration with our current Exchange 2010 DAG setup to exchange online. We have about 112 users to move so going with the cutover. We're going that way also to remove the ned of having an onsite exchange presents. Only thing that's I've been reading about is that you need to disable DirSync to perform the cutover migration. My question(s) are 1. Will disabling DirSync (which will move all users into the deleted users) stop SSO access to our over products we use day in and day out. 2. Does having an already synced Azure AD impact on the migration, IE will it duplicate users/mailboxes 3. Does having no exchange presences onsite with DirSync enabled (After migration) cause issues? we have no plan on moving back to onsite. We do plan on keeping users onsite and in azure with the Sync Thanks a bunch, I cant find any documentation that covers our specific scenarioADDS trusted forests.domains A. OnPrem EX2013 B.Office 365 into new ADDS and New 0365 Tenant?
Greetings. We have two company's (each with their own forest and single domain) that have operated in a trusted ADDS forest configuration. Each forest contains their own respective mail system. One has on-premise Exchange 2013. The other ADDS forest has O365 and uses Azure AD Connect to sync on-premise ADDS users to o365. These mail systems are utilizing Galsync (enow) to support cross forest GAL's. We are not (yet) using o365 SharePoint, one drive, or other 0365 services other than email. *We will later in the new named entity. We are now going to merge these two environments (ADDS forest(s) / domain(s)) into a new named ADDS entity (forest and domain) - and new o365 tenant. This new named entity will utilize many of the o365 offerings. I have migrated/merged trusted forests, and Exchange on-premise 2010/2013 systems together via ADMT and mailbox moves. This looks to be a bit more challenging. Has anyone performed a similar migration/merge? Would they be willing to share how they did it? Any insight, links, or thoughts are very much appreciated. I found something similar in a forum on reddit -https://www.reddit.com/r/Office365/comments/93f4oq/cross_forest_office_365_migration/ Thanks in advance,
Cutover migration of external domain without AD sync
Hey all was wondering if anyone is familiar with exchange migrations where you don't want to pull over the AD accounts. We acquired a company and want to migrate there exchange to our office 365 tennant but not sync there AD. We want to exchange server mainly for historical data and will convert them to shared mailboxes when imported, but I am unable to find an answer on weather this is possible or not.Email Deployment Issue
So I have backed myself into a corner with email migration to Office 365. I followed instructions from a vendor who sold us migration software, but it appears I am now in a bit of trouble. The goal was a cutover migration from a single on-prem Exchange server. We want to retire the on-prem server entirely and are not interested in running exchange at all on-prem. The instructions indicated setting an attribute on the AD Sync tool to be null: https://www.codetwo.com/kb/msexchmailboxguid-problems/ which would allow the mailboxes to be created on Office 365. That worked like a charm. We used the software to migrate the content, repointed MX records. At this point mail flowed properly into Office 365 and were able to repoint the clients. All is working, EXCEPT: we can't make any changes to mailboxes on Office 365 and we aren't able to retire our exchange server because it's being used to manage the mailboxes. So I'm looking for a plan to fix this situation that won't break everything. We seem to be stuck in between a cutover and hybrid migration and have gone non-standard. Before criticizing, please understand that I was following instructions from CodeTwo exactly. I realize its a mistake now, but I'm looking for a way out. I have a bit of a plan, but I'm looking for feedback from the experts: 1. completely disable and uninstall AD Syn tool, which should allow the mailboxes to be managed on Office 365. 2. decommission the exchange server, which I'm thinking will remove all email/exchange attributes within AD. AD will no longer be tied to Exchange for email in any way. 3. reinstall AD Sync tool which at this point will not be synching email attributes, allowing the mailboxes to continue to be managed on Office 365. Any thoughts on this plan?
