Posts Tagged domain name system
Last week the next version of Office 365 was released by way of a public preview. This launch took place with little fanfare as all the attention seemed to be on the new Office 2013 suite. But the next versions of Lync, Exchange and Sharepoint are now all available as a part of the Enterprise experience of Office 2013 and of course the back-end Office 365 products. If you wish to sign up for a preview go here: http://www.microsoft.com/office/preview/en/try-office-preview .
I thought it would be timely to repeat some of the information gained over the past few months, recycle if you will, some key articles that will guide you with a move to the new platform. As with any tenant to tenant migration of Office 365, there are certain steps you need to perform in order to move your domain across. As stated previously you need access to your DNS records and some knowledge of how that relates to your user accounts. I suggest you start here: http://itprofessional.co.nz/2012/03/07/migration-from-p-to-e/ Although this article speaks about a migration from the P plans of Office 365 (Small Business) to the E plan (Enterprise), the principals are the same when it comes to moving from Office 365 (current version) to the recently released Office 365 preview (Wave 15).
In addition to this, the final step is “releasing” or removing your domain from the old tenant, allowing you to associate it to the new tenant of Office 365. Your domain can only be associated with one tenant at any one time, so this step is critical in your migration. You will receive an error if you havent followed the correct steps first, removing all references to the domain from your current Office 365 tenant.
For a more detailed step by step guide on how to remove or dis-associate a domain from your Office 365 tenant go here: http://www.configureoffice365.com/remove-office-365-domain/.
The new version of Office 365 is due to be released later this year and customers can sign up for the beta on a 9 month free trial for 25 seats. So if you are at the bleeding edge of technology adoption I suggest you make the move and discover what the next version of Office has to offer.
One of the things that impresses me with the cloud offerings from Microsoft is the great partner community dedicated to delivering the solution. In this blog I want to talk about the experience I had recently moving a customer from the P Plan of Office 365 to the E Plan. I talked about the reasons why this migration became necessary in my earlier blog post . In this post I will talk about the migration of the DNS records and the mail data, as we are deploying CRM Online we will not be transferring any existing Sharepoint configuration, rather bulk copy the files using explorer to the new Sharepoint structure.
Microsoft have their own reasons for creating two separate product offerings within Office 365, one of which is the Google compete aspect. The P plan is a direct competitor with Google Apps/Docs/Mail and is priced accordingly, it does however miss out on a few important features, SSL (secure) connection to Sharepoint Online, more than 25 users (50 users hard limit), no Active Directory integration to list a few. Microsoft don’t currently offer customers any tools to migrate from the P Plan to the E Plan and you can’t purchase E Plan licenses from a P Plan tenant. This is where a partner steps in to make life extremely easy, MigrationWiz have been at the forefront of providing cloud migration tools for a number of years now, my first interaction with them came when I wanted to migrate a customer from Gmail to BPOS – Microsoft Online Services back in 2010.
The experience with MigrationWiz has only become better since my last trial. The interface is slick and easy to understand and for around US$10 per mailbox it just doesn’t make sense to attempt to migrate any other way. I would suggest that Microsoft purchase MigrationWiz but then again I appreciate the neutrality provided by their current position. There are a few things you need to understand when performing such a migration and while simple to understand, they may interrupt your services and/or mail flow.
Understand your DNS, this has to be the most important part of the migration. I spoke earlier about DNS Records and in this case too you will need to make changes to these records. The DNS record allowing you to route mail and authenticate users is only able to be associated with one tenant of Office 365, so if you are migrating to another tenant as in this case you will need to plan when to move this record across.
You will get an error when you attempt this in Office 365 if the domain is associated with another tenant.
I suggest that you choose a weekend to migrate your customer as the DNS changes may take up to 24 hours to complete. It needs to start with “releasing” or deleting the DNS record from the old tenant, this will initiate some hidden scripts which de-provision the record from the services in the back end. It is important to understand that at this stage you will still be able to access the user accounts using their tenant alias @.onmicrosoft.com . Email will stop at this time, you could employ the use of a “mail bagging” service, usually provided by your ISP, make some enquiries as it will prevent email from being dropped in the time you take to transfer the record to the new tenant. Changing your MX record at this time to the mail bagging service will prevent mail from being dropped. The domain name will take some time to be released from the old tenant, Microsoft advise this could be up to 24 hours, if after 24 hours it still won’t allow you to verify the domain in the new tenant then make a call to Microsoft Support and they will manually release the record. Once you have verified the domain in the new tenant of Office 365 you will then be able to redirect the MX record again, pointing it to the Office 365 servers. Again this should be completed on a weekend or an outage window of at least 24 hours.
I used the premium license of MigrationWiz as I wanted to make a couple of passes to migrate the mail. The other thing this allows you to do is perform a complete migration without interrupting any mail flow for the customer. At a cost of US$11.99 per mailbox it was only $2 more than the standard single pass license. Before I migrated any mail data I needed to ensure the mailboxes I was migrating to existed in the new tenant.
Having purchased the P Plan originally I had no Active Directory federation or synchronization to worry about, Microsoft gave me a couple of great tools to create the user accounts by way of uploading a CSV file with the usernames in it, this was exported from the old tenant of Office 365 using the free poweshell cmdlets, if you don’t know how to use Powershell i highly recommend you do as it will make life a lot easier. When importing the users from the CSV file you will need to change the user account ID to use the default tenant id @.onmicrosoft.com as the domain will not be verified yet.
This CSV file can then be modified and used in the MigrationWiz portal to configure the mailboxes you want to migrate. Credentials can be that of an administrator, as administrator accounts have access to all users mailboxes.
As you can see from the screenshot above, the console in MigrationWiz is clean and easy to understand, mirroring the experience had within the Office 365 environment. The status of the migration can be seen at a glance and any errors are easy to identify and fix. The beauty of using a cloud to cloud service is that my bandwidth isn’t used, all the data is transferred direct from one data center to another. Be aware that the migration does take some time therefore I would recommend using the premium license of MigrationWiz that allows you to make more than one pass of the mailboxes, the first, a week before the migration date and once again after the MX records have been migrated. Contacts, Calendar and email folders are migrated using this method and users will not notice the difference when they connect to their new mailbox.
The last thing to remember is that the user’s passwords will need to be changed. I this case I logged into every account and changed the users passwords via the portal. This was fine for the 20 user accounts I was migrating, however the Powershell cmdlets I mentioned earlier could have easily achieved the same result allowing you to set a default password for the new accounts. The auto discover record will allow the devices to automatically redirect the connection to the new mailbox.
I hope this has shown how easy a migration can be once you have chosen a cloud service, with the tools made available by Microsoft and more importantly by the partner community it can be achieved in a few easy steps.
I’ve spoken about the simplicity of a cloud solution and what it can offer. Now I want to cover off the changes you need to make to your current environment before making the move to the cloud.
Most companies out there have a website or at least a domain name which represents their business name or brand. This domain name becomes a part of a businesses identity and is usually the suffix for every employees email address. The Domain Name System or DNS record is where this information is stored; this DNS record is usually hosted or administered by your Internet Service Provider or ISP. In some cases a dedicated DNS registrar i.e. Godaddy, Freeparking or Network Solutions may host the DNS record.
Note: DNS record account information can be one of the hardest things to track down. Make sure you have this information available before signing up to any cloud service.
Migrating to any cloud service requires changes to the DNS records for a company. This isn’t as scary as it may sound however it may be more challenging that first thought. Not all DNS service providers are created equal and the lack of customization can cause a roadblock for your migration. It pays to be on top of things and get any DNS issues resolved first with your service provider.
The DNS changes for Office 365 are very simple however there is one record which may not be supported by your service provider. This record is called the SRV record and is used for Lync online Federation. Federation for Lync is important if you want to use Lync with other companies or communicate with people who have accounts on other messaging platforms such as Live Messenger etc. If you do not need the Federation functionality of Lync then the SRV record change is not required.
The other records that need to be changed/modified are:
- CNAME – This is a redirect record, it allows Office 365 to determine that you own the domain in question and also allows your clients to automatically detect the settings for Exchange Online and Lync Online.
- TXT – This record is used to assist Exchange
- MX – The MX record or Mail Exchanger is the one record that can interrupt your mail flow. This record is only changed once the migration to Office 365 or any cloud based email solution is complete. Be careful the MX record change can and will stop you from receiving any emails! I suggest making any changes to the MX records on the weekend.
These changes are only required for the Enterprise Plans within Office 365, the P Plan or the Small Business offering allows you to use Microsoft to host your DNS records, you will still need to make changes to the Name Server of your DNS record, again this is done via your ISP or existing DNS registrar.
For more information go to the Office 365 support pages: here
Changes to DNS records are made either via a portal provided by your ISP or over the phone. 99% of the time the ISP will provide a portal which requires a specific syntax to make the change. As I said before, some ISP’s may only give a very basic interface that may not allow you to make some changes. Make yourself familiar with the experience before proceeding with your migration.
Within Office 365 you are able to add as many domains as you wish and have multiple email addresses associated with every user. Once you have registered a domain name you can now use that as the default username for the services.
Ill talk about how to get your data into the cloud in my next post…