We had an interesting Skype migration, where we needed to migrate 10,000 numbers from BT to Microsoft Phone System for Skype for Business.
With BT you have to port the entire block in one go, so we had no way of porting numbers in batches as users migrated over to Skype for Business. So, we needed a way for users to continue to be able to receive calls as they migrated onto S4B, but whilst the numbers were still with BT. Since calls were still coming into an old PBX, the initial thought was to program the PBX to forward numbers as and when users were migrated. However, since we were migrating about 100 users a day, this would basically be a full time job to program all the forwarders on the PBX, and would also be very prone to error, since the old PBX had to be programmed via a terminal application with no scripting support.
However, we realised that users were already used to forwarding their own numbers to their mobile phones, so they can forward their own calls in this way using their desk phone (a feature of the old PBX). What we therefore did was allocate 10,000 temporary local numbers in Skype for Business, and then ask each user to forward on their old desk phone to their temporary number as they get migrated. Once this is done, users receive all their calls on their old number using S4B (either client or Polycom desk phone), and can make outbound calls (which doesn’t show their number anyway). This made the whole migration process a lot easier, and placed the onus on the user to set up a simple call forward, less prone to error and easy for them to correct if they make a mistake.
The final job will be one off number port, at which point we will map all the ported numbers to the users using a PowerShell script, and job done!
PowerShell won’t update help, or let you connect to online repositories, without configuring it to work with your corporate web proxy servers. Unfortunately it does not use the system settings, so you have to do this manually.
If you try and use an online command such as update-help, you will get an error like this:
PS C:\WINDOWS\system32> update-help
update-help : Failed to update Help for the module(s)'ActiveDirectory, AppBackgroundTask, AppLocker, AppvClient,
Appx, AssignedAccess, BestPractices, BitLocker, BitsTransfer, BranchCache, CimCmdlets, ClusterAwareUpdating, ….Unable to
connect to Help content. The server on which Help content is stored might not be available. Verify that the server is
available, or wait until the server is back online, and then try the command again.
To fix this, you need to configure your proxy settings in your PowerShell profile as follows (note that this requires local administrator rights):
Open an administrator-level PowerShell command prompt
Run the following command to register the PSGallery Repository
Register-PSRepository -Default -Verbose
Then you will be able to edit your profile:
Note: it will prompt you to create this if it does not exist. Then add the following lines, modifying as you see fit for your environment: [cc lang="powershell"] [system.net.webrequest]::defaultwebproxy =new-object system.net.webproxy('http://proxyname:port')
This is a workaround in order to migrate mailboxes to Office 365 which have special characters.
You may run into an issue migrating from on premise Exchange to Office 365, where some accounts fail due to illegal characters in email addresses or UPNs. Having spoken to Microsoft about this, the official line is that no special characters are supported, therefore you should remove them if at all possible. However, we found during a large migration that in some cases they can be retained.
Note that the Microsoft article linked below does not mention UPNs, however we found that special characters in UPNs will cause users and shared mailbox migrations to fail.
The result of our testing was as follows:
Distribution Lists don’t require any changes and will still work
User accounts and shared mailboxes need any illegal characters removing from UPN, mail and primary SMTP address in proxyaddresses attribute, but these can be added back in as SMTP aliases, and should then be retained once the account is migrated.
Note: I would suggest that special characters are simply removed, rather than replaced with anything else. There are different types of characters, so removing them works for anything. It is not required to change the Display Name in the GAL, only the email address and whilst that is what people will see if they reply to an email, and they will still receive emails on the old address. This will be very difficult to manage if we have different rules for different areas of the business, different characters etc.
You can follow the process below to make changes to affected accounts in your on premise Active Directory before they can be migrated. To be clear, the process is as follows (for users and shared mailboxes):
Remove any special characters from UPN, mail, and primary SMTP address
Add back the primary SMTP address as an alias (if still required)
All other aliases and attributes can remain as-is, including display name.
Display name: R&D Team Mailbox – leave as-is
UPN: Change R&DTeamMailbox to RDTeamMailbox
Change Primary SMTP: From R&DTeamMailbox.com to RDTeamMailbox@domain.com (remove &)
Add back the primary address as an alias: R&DTeamMailbox.com