SQL Database Migration – 2000 to 2012
Recently a client came to me asking to migrate an old SQL database from SQL2000 over to their primary SQL server (SQL2012). As most of you most likely know, there is no direct migration path from SQL2000 to SQL2012.
To ensure that the migration was done as quickly as possible with minimal down-time, we needed to bring in an SQL2005 or SQL2008 instance to be the ‘middle man’. In this case, we used SQL2008, as it was readily available and we could install it straight away (without having to wait for the ISO to download etc).
In order to successfully migrate the database from SQL2000 to SQL2012, we have to export the databases from 2000, then import them into 2008. Confirm that it’s been restored successfully into the 2008 instance. Once we’ve done that, you can now export the databases again from the 2008 instance. The process from here is rather simple. Just import the new .bak files into the SQL2012 server and it should work without any problems.
There is no need to create a new server for this job. You can simply install a SQL2008 or SQL2005 instance on the existing server (that you’re planning to decommission), do the migration and then remove it.
Unable to Access Exchange Management Console 2010
Recently I was on a new client’s server and I accessed the Exchange Management Console for Exchange 2010. When expanding “Microsoft Exchange On-Premises”, I received the following error message:
In order to get around this, you must look at the Security Group called Organisation Management. Check the membership of this group, and ensure that the user account you’re using to open up EMC is within this group. In this case, my user account hadn’t been added to this group which was why I received that error message.
After adding my user account to the group, I clicked Retry within EMC, and it worked perfectly for me.
Azure AD Connect not syncing to Office 365
Recently we received a call from a client advising that he was in the Office 365 Admin Portal, and noticed that there hadn’t been a sync for the last 3 days or so. He’d asked us to log in and take a look.
DirSync, or Azure AD Connect as it is now called, relies on two account credentials to work properly. A domain admin account, and an admin O365 account. Generally, you will create a service account for Azure AD Connect, mark it as a Domain Admin, and then never change the password again. The Admin Account you should rarely change the password to either.
In this case, the password for the Office 365 Admin account had been reset, which caused authentication to fail and the sync to no longer work. Running the Azure AD Connect wizard again to re-enter the new credentials will resolve this issue straight away, and you will notice the synchronisation happening immediately.
