Salaam, Namaste, Ola and Hello!

Welcome citizen to the ‘I am IT Geek’ blog!  This is part 2 of my experience with Azure Active Directory Migration a few years ago.

In part one I set the scene and explained how we ended up with Azure AD as the solution to meet this customers requirements, but all this was still theory.  Due to this technology being relativity new at the time, the customer wanted a Proof of Concept (POC) setting up and then to test with live users.  The main purpose of this was to enable us to document the migration process but at the same time iron out any potential issues before the mass migration to over 300 users.

Before POC could take place I needed to ensure the back-end Azure and Intune was setup correctly.  With this particular customer, as they already used Office 365, SharePoint online and Sky for Business, the Azure Active Directory was already setup and working.  The Intune setup was simple enough: Enable Intune via Azure AD, Create a Security Group for the Intune policy and assign the relevant users to this group and finally configure the Intune Policy.

Currently the Intune policy options are what I would call ‘Basic’ as you only really have a handful of security like settings (password length, Password type, password lockout etc).  At the time of writing this Intune is very much in it’s infancy but knowing Microsoft it will be a service that will develop very quickly.

With the basics of the policy completed there was some final testing to complete around profile migration, which ended up being the trickiest part.  The main reason for this being a requirement was that when you add a Windows 10 device to the Azure Domain it creates a new blank profile, much like it would if you were to add the any on premises domain.  In the end we found a great tool called ‘ForensiT User Profile Wizard’ which basically migrated the old local profile into the new Azure AD profile.  The slight caveat to this was that it did not migrate Google password store as this is encrypted, but logging into Google with the users gmail account got round this issue.

The POC was a massive success with the group of test users being migrated seamlessly and once migrated saw no difference in there daily work which was a massive positive.  In a way that is always a massive aim with any type of migration…make the impact to users as little as possible!

Due to the size of the migration being so wide (offices all over the world), my scope was to roll out Azure AD to the UK based users and provide documentation to allow the Global Infrastructure team to slowly migrate the global users onto the platform.  The main migration was a massive success which was all down to the careful planning, testing and documentation done in the build up.

Since the migration I have worked with the customer to implement Single sign on for 3rd party apps via Azure including SalesForce as well as deploying applications via Intune which just shows how they are embracing the platform!

Thanks for reading, I hope you enjoyed this two part blog of my experience with and Azure AD implementation/migration! Until next time, ‘I am IT geek’ over and out!

Salaam, Namaste, Ola and Hello!

Welcome to ‘I am IT geeks’ first technical blog!!  As i explained in my introduction i will be blogging about my own experiences working in the IT industry.  The first experience i will be talking to you about today is a recent Azure Active Directory migration i managed for a customer who is based in the Financial sector.

Setting the Scene – This particular customer was already using Office 365, SharePoint online and Skype for Business in addition to a Cloud based VOIP system, so you could say they were already big fans of ‘The Cloud’.  The issue they had was that every user laptop was on its own work group! That’s right citizen…in 2017 there are people still in work groups….even multi million pound corporations!  With GDPR fast approaching the customer needed a solution that would allow them to secure and manage devices whilst ensuring they are compliant….Enter Azure AD!

The initial discussions we around putting in a VM within Azure and promoting this to a Domain Controller, however i soon came to the conclusion that this was not going to be the right solution.  This particular customer is a Global Financial Consultants so have lots of small offices around the globe.  To make the Domain Controller VM in Azure work it would have required a Site-to-Site VPN from Azure to each office location they wanted to utilize which would mean a lot of management overhead.

As you can see it looks simple enough from a high level overview as above, but the issues i found were more specific.  For example the Azure VPN has a list of supported Firewall/Router vendors and model’s, however that does not mean it wont work with ones that are not on the list.  Unfortunately for me this customer had different routers at each site, which again added to the management overhead.  Another stumbling block was the number of Site-to-Site VPNs that were supported.  In this case we were using the Basic S2S VPN which supports a maximum of 10, however the number of remote offices exceeded this.

I was quickly realizing that i needed a plan B which I found in the form of Azure AD!  Not only did it solve the problems the S2S VPN was providing, but with the addition of a Enterprise Mobility & Security license it opened up a whole new range of possibilities to the customer.  With the EM&S license, all the sudden Single Sign on to 3rd party apps like Slack, DropBox and Sales Force was possible.  Multi Factor Authentication was no longer a pipe dream. And the cherry on top of this Azure cake was Azure Intune and its MDM feature, allowing the customer device management, auditing and reporting that was previously not available.

With GDPR just around the corner Azure Intune was a key factor in the customer deciding to deploy Azure AD and EMS across the business….however citizen you will need to wait for part 2 of this blog to see how the migration went so until next time, ‘I am It Geek’ over and out!