A few posts on this since it’s what I’m working on :)
It is possible to sync all your mailboxes from Exchange On-Prem to Exchange Online as a single batch, and then complete individual items – but it’s not obvious that this is even possible.
Normally if you start a migration, you can choose multiple mailboxes or use a CSV file to specify which accounts to start migrating – while specifying the option to manually complete the batch, so the actual migration happens when you want it to:
The problem is, once you’ve fixed any problems that arise and mailboxes are in a ‘synced’ state, there’s no visible way to complete a single mailbox – just the whole batch. That may not be what you want to do. You could work out a way to create a separate batch for every single mailbox you’re migrating, but there’s also a way to complete one mailbox at a time.
In PowerShell, once you’ve connected to Exchange Online, you can run the a command to see all the mailboxes syncing, and their status:
If a mailbox is ready to be finalised, it should have the status of ‘Synced’. This is different to the status of ‘Completed’, which occurs once the mailbox has been fully migrated across.
To trigger the completion of a single mailbox in a batch, use this PowerShell command:
The mailbox will then do it’s final syncing and complete, without affecting the other jobs in the same batch. The -CompleteAfter parameter is supposed to set the delay before the request is completed in date/time format, but using the value ‘1’ seems to immediately trigger this.
Now you can do a single batch job, and selectively complete mailboxes as you choose – easy!
(Note that there was an old method of doing the above by setting the variable SuspendWhenReadytoComplete to $false which no longer works)
Keep in mind that this process locks down the Start Menu tiles completely, users won’t be able to add, remove or change anything to do with tiles.
The first step is to configure the Start Menu tiles how you want them on a computer. You can add, remove, move, resize etc until you’re happy with how it looks.
Once that’s done, you’ll need to export the layout to an XML file. Easily done by opening PowerShell and running Export-StartLayout. This needs the -Path switch, e.g. Export-StartLayout -Path “C:\temp\startmenu.xml”
Copy the resulting startmenu.xml file into a central location that clients will be able to access, or copy it out to each machine through Group Policy Preferences. This XML file will be called in the Group Policy setting “Start Layout”.
The Group Policy setting called “Start Layout” lives in User Configuration or Computer Configuration > Policies> > Administrative Templates >Start Menu and Taskbar. You’ll probably want this at the user level rather than the computer level, but it depends at what layer you want this locked down at.
If you can’t see this policy at all, then you may need to update your Group Policy templates. Each time a new version of Windows 10 comes out, there’s usually new or updated Group Policies to use. There’s a good step-by-step here if you need help – I’d recommend downloading the templates that match the latest version of Windows 10 you’re managing.
Start Layout in Group Policy
For this policy, you’ll be setting the radio button to Enabled, and setting the Start Layout File value to the path of the XML file that you copied out or placed centrally.
Start Layout Settings
Once that is done, the Group Policy object containing this setting needs to be pointed at the users or computers you want it to apply to, just like any other Group Policy.
The end result is the client then having the same Start Menu tiles configured in the XML file.
You may find that some of the tiles are missing. I’ve seen this happen when the shortcut the XML points to isn’t in the location expected. Here’s an example XML file with just one tile configured for Notepad:
When a Tile is added to the Start Menu, if it doesn’t exist already, it will create a .LNK file and uses that for the tile. You may need to copy these off the computer you created the tiles on the in first place too, and copy them out to the same path on the computers you’re pushing this setting to.
You can also manually update or change the XML file yourself, which can sometimes be easier than going through the whole export process again.
One last thought I have on this, is that you can have multiple XML files going to different computers or users based on their requirements – but don’t over complicate things or you’ll be constantly managing tiles!
I had a requirement come up where I needed a list of Exchange Online users as well as Exchange On-Premises users. If you’re hybrid or going through a long migration, there’s many scenarios where you want certain products or settings applied against the users and accounts based on where their mailbox is.
You could maintain that manually, but why do that when you can automate it!
Thankfully there’s two easy commands that will return accounts based on where they are – get-mailbox and get-remotemailbox. As long as you’re in Exchange Hybrid mode, you can run both of these commands against your local Exchange server.
All I’m doing here is getting the two user types and putting them into variables – $remoteusers and $onpremusers. I’ve also used the group names as variables, so you can create whatever AD groups you like and put them into the $remotegroup and $onpremgroup variables.
Also I’m clearing out all members of the group before adding users, which means if someone gets migrated or leaves, they’ll be cleaned up from the old group properly.
Finally I’m going through the two users lists and using ‘foreach’ to add each user to the relevant group, using the SamAccountName value of each result to identify them.
It’s only a basic script, but you can easily add extra filters to the Get-Mailbox and Get-RemoteMailbox commands to do things such as only getting users from certain OUs.
This was tested on Exchange 2010, so if you get different results on Exchange 2013 or 2016 please let me know.
In SharePoint Online, it’s easy to delete an entire site or documents in a site.
Recovering documents is also quite easy, go to the site’s recycle bin which is normally located at https://contoso.sharepoint.com/sites/sitename/_layouts/15/RecycleBin.aspx – replacing ‘contoso’ with your tenant name, and ‘sitename’ with the actual site name. Deleted items can be selected and restored to their original location.
In SharePoint Online, the default retention time is 93 days for both site recycle bin (first stage) and site collection recycle bin (second stage). The site recycle bin storage counts against your site collection storage quota and the List View Threshold. The site collection recycle bin retention starts at the same time for both recycle bins when the item is first deleted, so the total maximum retention time is 93 days for both recycle bins. The default amount of space for the site collection is 200% of the site collection quota.”
However, I had some issues when trying to recover an entire site. My top level recycle bin https://contoso.sharepoint.com/_layouts/15/RecycleBin.aspx showed nothing. I’m unsure if there’s another way of viewing deleted sites via the web interface, and gave up after a lot of clicking around and Googling, but it’s easy to do with PowerShell.
After installing the SharePoint Online Management Shell, and connecting to SharePoint Online with the ‘Connect-SPOService‘ cmdlet (and don’t forget to use HTTPS rather than HTTP when connecting to your SharePoint Online instance or you’ll get a rather generic error: connect-sposervice : Could not authenticate to SharePoint Online http://contoso-admin.sharepoint.com/ using OAuth 2.0), you can see what your deleted sites are with this command:
Simple, you’ll then be presented with a list of all sites that are deleted and waiting in the recycle bin along with when they were deleted, and how many days are remaining before they disappear from the recycle bin. Sites deleted seem to sit in that recycle bin for 30 days, rather than site collection items but I couldn’t find any documentation supporting this.
To restore a deleted site, just use the following command with the URL of the site to restore, which you can see from the ‘get’ command above
Wanting to have all users to have the country ‘Australia’ in Active Directory, I thought it would be a simple PowerShell command. Get all the users you want and set a field to ‘Australia’. However, it’s more complicated than that.
As you can see from the above, the Country/region field is a dropdown, where you can select the country. If you look in PowerShell using ‘get-aduser username -properties *’, there’s 4 fields that get populated with this setting:
c : AU
co : Australia
Country : AU
Trying to just change one of these fields will result in an error such as:
Set-ADUser : A positional parameter cannot be found that accepts argument ‘Au’. Set-ADUser : A positional parameter cannot be found that accepts argument ‘Australia’. Set-ADUser : A value for the attribute was not in the acceptable range of values
The answer is that all fields need to be set at the same time. The C and Country fields are based on ISO 3166 codes, with Australia being AU and 36.