The Great ‘Cloud Repatriation’

Cloud Repatriation KB ID 0001859

Cloud Repatriation The Great Cloud Migration Reversal

In the fast-paced world of technology, trends often come and go with dizzying speed. One such trend that took the business world by storm was the mass migration to public cloud environments. For years, companies embraced the promise of agility, scalability, and cost-effectiveness offered by the public cloud. However, recent surveys and industry reports indicate a significant shift in this narrative—a growing number of organizations are repatriating their workloads from the public cloud back to on-premises infrastructures. What’s driving this reversal, and what does it mean for the future of cloud computing?

According to the DC Cloud and AI Adoption Survey dating as far back as 2018, a staggering 80% of customers expressed their intentions to repatriate workloads from public cloud environments. This sentiment has only strengthened over time. Citrix’s recent findings further illuminate this trend, reporting that 25% of organizations surveyed in the United Kingdom have already moved half or more of their cloud-based workloads back to on-premises infrastructures. These statistics paint a clear picture of a paradigm shift in cloud adoption strategies.

One of the primary catalysts for this repatriation movement is cost. While the public cloud initially lured businesses with promises of lower operational expenses, many have found themselves grappling with unexpected costs and complex pricing structures. As organisations delve deeper into their cloud usage, they often discover that the anticipated savings are elusive, overshadowed by hidden fees and overprovisioning. The allure of agility, while undeniable, is no longer enough to offset the financial concerns associated with public cloud services.

Moreover, the recent acquisition of VMware by Broadcom has raised concerns, particularly among small businesses, about the future of their cloud infrastructure. With consolidation in the industry, smaller players may find themselves at the mercy of larger corporations, prompting them to explore alternative solutions such as edge computing or investing in their own on-premises infrastructure.

Another significant factor contributing to the repatriation trend is service reliability. While public cloud providers tout impressive uptime guarantees, the reality is that even the largest hyperscalers are not immune to outages. When a major cloud service goes down, the impact can be catastrophic for businesses reliant on that infrastructure. Clients often feel powerless and insignificant during these outages, underscoring the importance of reliability and customer-centric service.

Storage costs also play a pivotal role in the decision to repatriate workloads. While public cloud providers offer convenient storage solutions, the costs can quickly escalate, especially for organizations with large volumes of data. Hybrid cloud, private cloud, or outsourcing to local providers offer more cost-effective alternatives, with the added benefit of greater control over data management and security.

In conclusion, the pendulum of cloud adoption is swinging back towards on-premises infrastructures as organizations reevaluate their priorities and weigh the trade-offs of public cloud services. While the public cloud undoubtedly revolutionized the way we approach IT infrastructure, its limitations and shortcomings have prompted a reexamination of cloud strategies. As businesses seek to optimize costs, enhance reliability, and regain control over their data, the trend of cloud repatriation is likely to continue gaining momentum in the years to come.

Cloud Repatriation: Client Challenges

Undertaking cloud repatriation poses several challenges for clients. These challenges can vary depending on factors such as the size of the organization, the complexity of their IT landscape, and their specific requirements.  Common challenges facing clients undertaking cloud repatriation:

  • Data Transfer and Migration: Moving data and applications from the public cloud to on-premises infrastructure or alternative cloud environments can be a complex and time-consuming process. Clients must carefully plan and execute data transfer and migration strategies to ensure minimal disruption to their operations and data integrity.
  • Integration and Compatibility: Workloads that were designed to run in a public cloud environment may have dependencies on cloud-specific services or technologies. Clients may encounter challenges when integrating these workloads with their on-premises infrastructure or alternative cloud solutions, particularly if there are compatibility issues or differences in architecture.
  • Resource Allocation and Capacity Planning: Repatriating workloads requires clients to allocate sufficient resources and capacity within their on-premises infrastructure to accommodate the migrated applications and data. Proper capacity planning is essential to ensure optimal performance and scalability without over-provisioning or underutilizing resources.
  • Skill Gaps and Training: Managing on-premises infrastructure or alternative cloud environments often requires different skill sets compared to managing public cloud services. Clients may face challenges related to skill gaps among their IT staff and the need for training or hiring resources with expertise in areas such as infrastructure management, networking, and security.
  • Security and Compliance: Security and compliance considerations are paramount when repatriating sensitive data and applications from the public cloud. Clients must ensure that their on-premises infrastructure or alternative cloud solutions meet the necessary security standards and compliance requirements, including data protection, access controls, and regulatory mandates.
  • Cost Management: While cost savings may be a driving factor behind cloud repatriation, clients must carefully evaluate the total cost of ownership (TCO) associated with migrating workloads back on-premises or to alternative cloud solutions. This includes not only the direct costs of infrastructure, but also factors such as licensing, maintenance, and operational expenses.
  • Service Levels and Performance: Clients may have become accustomed to the scalability and performance benefits of public cloud services and expect similar levels of service from their on-premises infrastructure or alternative cloud solutions. Ensuring that the repatriated workloads meet performance requirements and service level agreements (SLAs) can be a challenge, particularly in highly dynamic or resource-intensive environments.
  • Vendor Lock-In and Flexibility: Repatriating workloads from a specific public cloud provider may involve mitigating vendor lock-in and ensuring flexibility to migrate between different environments in the future. Clients should carefully evaluate vendor dependencies and consider strategies for maintaining portability and avoiding vendor lock-in when repatriating their workloads.

To summarise clients undertaking cloud repatriation face a range of challenges related to data migration, integration, resource allocation, skill gaps, security, cost management, service levels, and vendor lock-in. Addressing these challenges requires careful planning, collaboration between IT teams and stakeholders, and a strategic approach to migrating and managing workloads across different environment.

Related Articles, References, Credits, or External Links

NA

Insufficient access rights Error Code 8344

Error Code 8344 KB ID 0001636

Problem

With Azure AD Replication, you may notice that you have the following error when you take a look at your connector status;

Error: permission-issue
Connected data source error code: 8344
Connected data  source error: Insufficient access rights to perform this operation.

Solution: Error Code 8344

Firstly ensure that the user you are running AAD sync under, has the following permissions on the ‘root’ of your local AD domain.

  • Replicating Directory Changes: Allow
  • Replicating Directory Changes All: Allow

If the problem persists it’s usually because the account that is running the AAD sync does not have the appropriate rights to the mS-DS-ConsitencyGuid attribute for the affected users in the local Active Directory. The following commands will add the appropriate rights you ALL your local users;

[box]

$accountName = "Domain-Name\User-Name" 
$ForestDN = "DC=Domain-Name,DC=Domain-Extension"
$cmd = "dsacls '$ForestDN' /I:S /G '`"$accountName`":WP;ms-ds-consistencyGuid;user'"
Invoke-Expression $cmd

[/box]

Lastly, if you have this problem on some ‘sporadic’ users, check to ensure that their individual user objects and inheritance enabled on their user object, before retrying.

 

If the problem persists use the AD Connect Troubleshooter.

Fix Error Code 8344 with AD Connect Troubleshooter

Open Azure AD Connect > Configure.

Troubleshoot > Next > Troubleshooting > Launch.

Option 4 > Note: At this point you may or may not be asked to install the RTSAT tools, if so enter Y {Enter} > Option 12 > Y {Enter} > E {Enter} > Type in the name of the connector (in the example below that’s pnl.com).

You will be prompted to authenticate with an administrative account > You will then have to accept each change, by typing A {Enter} You will need to do this SEVEN TIMES.

When complete force a full initial replication.

[box]

Start-ADSyncCycle -PolicyType Initial

[/box]

At this point go an have a cup of coffee, then come back and check Synchronisation Service Manager. You should now be error free.

Related Articles, References, Credits, or External Links

NA

Azure: Point to Site VPN From mac OS?

KB ID 0001693

Problem

We mac users always get overlooked. If I had a pound for every time I’ve heard ‘Yeah we don’t support macs?” I would be a rich man. But thankfully this makes us work things out for ourselves usually!

So recently I did a article Azure: Point To Site VPN (Remote Access User VPN) but what if you want to use the same solution for a remote mac user?

Solution

Firstly you will want to download the VPN package (and have a valid client/user certificate, [see the link above]).

Obviously the installer is for Windows, but within the ZIP file you download, it has a copy of the XML file with the settings in it, and a copy of the Root CA certificate you used.

So your first job is to ‘import‘ the client certificate, it will be in PFX format, (if you followed my instructions), so you will need to supply the password you specified when creating the PFX file (not the mac password), when prompted to install it (double click on it).

The engineer in me isn’t quite sure why the client needs the Root CA certificate on it, (because that’s not how certificates work!) But Microsoft insist it’s necessary, so also double click and install the Root CA Certificate, (it’s inside the VPN Package).

You don’t need to install VPN software onto the mac, (it has its own built in). Click the Apple Logo > System Preferences > Network > Add > Interface = VPN > VPN Type = IKEv2 > Service Name = Azure-Client-VPN > Create.

Now open the XML file from within you VPN client software ZIP file, and locate the FQDN of the ‘Gateway’ address in Azure > Copy it to the clipboard.

Paste the server address into BOTH Server Address AND Remote ID > (Leave Local ID blank for now) > Authentication Settings

WARNING: I’m using mac OS Catalina, so I choose ‘None’ (NOT CERTIFICATE). But for mac OS Mojave (and older) CHOOSE CERTIFICATE). It’s a bug that causes an error (see below) if you don’t.

Select > Choose the CLIENT certificate you imported earlier, (Take note of the name in brackets, this is the common name on the certificate). You will need this in a minute!  > Continue > OK.

Put the Common Name from the certificate into the Local ID section > Apply > Connect.

All being well it should connect, (though it may prompt for you to enter your user password). BY DEFAULT the option ‘Show VPN Status in Menu Bar‘ should be ticked, if it isn’t then tick it.

With that option ticked, you can connect and disconnect the VPN quickly without needing to go back into System Preferences like so;

Error: VPN Connection, ‘An unexpected error occurred’

Remember above when I said choose ‘None‘ for Catalina, NOT certificate? Well this is what happens if you choose certificate!

Related Articles, References, Credits, or External Links

NA

Azure VPN: Point To Site VPN (Remote Access)

KB ID 0001692

Problem

Given my background I’m usually more comfortable connecting to Azure with a Route Based VPN from a hardware device, like a Cisco ASA. I got an email this afternoon, a client had a server in a private cloud and a server in Azure, they needed to transfer files from the Azure server to the server in the private cloud. Now on further investigation this client had a Cisco vASA so a VPN was the best option for them, (probably).

But what if they didn’t? Or what if they were ‘working from home’ and needed to access their Azure servers that were not otherwise publicly accessible?

Well the Microsoft solution for that is called an ‘Azure Point to Site VPN‘, even though in the current Azure UI they’ve called it ‘User VPN Configuration‘, because ‘Hey! Screw consistency and documentation that goes out of date every time a developer has a bright idea, and updates the UI’ Note: I have a thing about things being changed in GUIs!

So regardless whether you are on or off the corporate LAN, you can connect to your Azure Virtual Networks.

Azure VPN (Remote Access)

This is not a full Azure tutorial, I’m assuming, as you want to connect to existing Azure resources, you will already have most of this setup already. But, just to quickly run through. You will need a Resource Group, and in that Resource Group you will need a Virtual Network. (Note: I like to delete the ‘default‘ subnet and create one with a sensible name).

So far so good, within your virtual network you will need to create, (if you don’t already have one,) a ‘Gateway Subnet‘. To annoy the other network engineers, I’ve made it a /24, but to be honest a /29 is usually good enough).

Now to terminate a VPN, you need a ‘Virtual Network Gateway‘.

Make sure it’s set for VPN (Route Based) > Connected to your Virtual Network  > Either create (or assign) a public IP to it. I told you I’d be quick, however the Gateway will take a few minutes to deploy, (time for a coffee.)

Azure VPN Certificate Requirement

For the purpose of this tutorial I’ll just create some certificates with PowerShell, (a root CA cert, and a client cert signed by that root certificate). This wont scale very well in a production environment. I’d suggest setting up a decent PKI infrastructure, Then using auto-enrolment for your users to get client certificates. However for our run through, execute the following TWO commands;

[box]

$cert = New-SelfSignedCertificate -Type Custom -KeySpec Signature -Subject "CN=Azure-VPN-Root-Cert" -KeyExportPolicy Exportable -HashAlgorithm sha256 -KeyLength 2048 -CertStoreLocation "Cert:\CurrentUser\My" -KeyUsageProperty Sign -KeyUsage CertSign

New-SelfSignedCertificate -Type Custom -DnsName Azure-VPN-Client-Cert -KeySpec Signature -Subject "CN=Azure-VPN-Client-Cert" -KeyExportPolicy Exportable -HashAlgorithm sha256 -KeyLength 2048 -CertStoreLocation "Cert:\CurrentUser\My" -Signer $cert -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2")

[/box]

Now launch ‘certmgr‘ and you will see the two certificates. Firstly, export the client certificate.

Yes you want to export the private key > You want to Save it as a .PFX file > Create a password for the certificate (MAKE NOTE OF IT!) > Save it somewhere you can get to, (you will need it in a minute).

Secondly, export the Root CA certificate.

 You DON’T export the private key > Save as Base-64 encoded > Again save it somewhere sensible, you will also need it in a minute.

Open the ROOT CA CERT with Notepad, and copy all the text BETWEEN —-BEGIN CERTIFICATE—- and —-END CERTIFICATE—- Note: This is unlike most scenarios, when working with PEM files, where you select everything, (it tripped me up!)

Back in Azure > Select your Virtual Network Gateway > Select ‘User VPN Connection’ (seriously, thanks Microsoft be consistent eh!) > ‘Configure now‘.

Pick an address pool for your remote clients to use, (make sure it does not overlap with any of your assets, and don’t use 192.168.1.0/24, or 192.168.0.0/24, Note: These will work, but most home networks use these ranges, and let’s not build in potential routing problems before we start!)

Choose IKEv2 and SSTP > Authentication Type = Azure Certificate > Enter your Root CA details, and paste in the PEM text, you copied above > Save > Time for another coffee!

When is stopped deploying, you can download the the VPN client software.

Azure Point to Site (User VPN) Client Configuration

So for your client(s) you will need the Client Certificate, (the one in PFX format,*) and the VPN Client software >  Double click the PFX file > Accept ‘Current User‘.

*Note: Unless you deployed user certificates already, and your corporate Root Cert was entered into Azure above.

Type in the certificate password you created above > Accept all the defaults.

Yes.

Now install the Client VPN software, you may get some security warnings, accept them and install.

Now you will have a configured VPN connection. I’m a keyboard warrior so I usually run ncpa.cpl to get to my network settings, (because it works on all versions of Windows back to NT4, and ‘developers’ haven’t changed the way it launches 1006 times!)

Launch the Connection > Connect > Tick the ‘Do not show…‘ option > Continue > If it works, everything will just disappear and you will be connected.

Related Articles, References, Credits, or External Links

NA

Veeam: Backup to Public Cloud?

KB ID 0001691

Problem

I’ve always been a fan of Veeam, I’ve championed it for years, as a consultant and engineer I want solutions that are easy to deploy, administer, and upgrade, that cause no problems. Like all things that are easy to use, and gain a lot of popularity, Veeam is starting to get DESTROYED BY DEVELOPMENT. What do I mean? Well, things that were simple and easy to find now require you to look at knowledge base articles and pull a ‘frowny face’. Also the quality of support has gone dramatically downhill. We stand at the point where another firm can come in and do what Veeam did, (march in and steal all the backup & replication revenue worldwide, with a product that simply works and is easy to use).

I digress (sorry). So you want to backup to public cloud yes?

Solution

Veeam Backup and Recovery Download

Veeam Backup For Azure Download

Veeam Backup for AWS Download

Well then, you log into Veeam look at your backup infrastructure, and simply add an External Repository and backup to that? NO! That would be common sense, (and the way Veeam used to to things). External Repositories are not for that, Veeam points this out when you try and add one;

So how do you backup to public cloud? (I know other vendors are available, but we are talking primarily about Azure and AWS). Well to do that you need to be more familiar with Scale Out Backup Repositories (SOBR).

With an SOBR you can add ‘cloud storage’ i.e. Azure Cold Blob storage or AWS S3, as ‘Capacity Tier‘ storage.  How is the Capacity Storage Tier Used? Well theres two options, ‘Backup to Capacity after x Days’ or ‘Backup to Capacity Tier as soon as backup are created‘. like so;

  1. Send your backup to a Scale Out Backup Repository.
  2. The backup gets placed into the Performance Tier.
  3. Option 1: Copy to Cloud after x Days, or Option 2: Copy to cloud immediately.

Note: This is configured on the SOBR configuration NOT on individual backup jobs/sets.

Adding Azure Cold Blob Storage

Well before you can add cloud storage to a SOBR you need to add it to Veeam, how’s that done? Well firstly you need to create an Azure Storage account.

Then generate an ‘Access Key‘.

Then create a ‘Container‘ in your storage account.

Then within Veeam > Options > Manage cloud credentials > Add > Add Azure Storage Account > Enter the Storage account and Access Key > OK.

Adding ‘Cloud Storage’ as ‘Capacity Tier’ to a Scale Out Backup Repository

Either create a new Scale Out Backup Repository, (Backup Infrastructure > Scale Out Backup Repository,) or edit an existing one. When you get to Capacity Tier > Tick the ‘Extend..’ option > Add > Microsoft Azure Blob Storage.

Azure Blob Storage > Give the storage a name > Next.

Select the storage account you created above > Select your Gateway Server (usually the Veeam B&R server but it does not have to be) > Next > Browse.

Select or create a new folder > Limit the amount of space to use (if required) > Next > Finish.

What about AWS? Well Microsoft kindly give me a certain amount of ‘free‘ Azure credits every month so it’s easy to showcase their product, (I use this for learning and PNL tutorials), so Microsoft pretty much get the benefit. I know AWS have a free tier and a trial tier, but honestly after spending 2 hours trying to find out what you actually get, and am I going to get stung on my credit card bill If I do ‘xyz‘ I lost all interest!

AWS, be like Veeam used to be, make it easy! AWS is like flying with Ryanair,

Oh so you want a seat? That will be and extra £x a month, and for every trip to the toilet will be an extra £x a month. Will you be wanting nuts? Because we charge by the nut, and no one knows how many nuts are in each bag, so it will be different every time, and speaking of time if you want to look at the clock that will be £x a month also!

People will email me and complain Azure is the same, and to an certain extent I will agree, but nothing will change until, public cloud providers start charging fixed prices for things, so IT departments can work out what the Opex is going to be e.g. like private cloud providers do! Of course working for a private cloud provider maybe I’m a little biased? 

Related Articles, References, Credits, or External Links

NA

Azure AD Connector: Disable ADFS Authentication

KB ID 0001643

Problem

Why would you want to disable ADFS authentication? Well what if ADFS is down, or you want to revert to some other authentication method? I was in a position a few weeks ago where I needed to disable ADFS on a clients Azure AD Sync. At that time the Microsoft Tech on the phone steered us towards doing what I can only describe as a ‘forced de-federation’. This involved using Powershell and it resets the password on all the ‘cloud’ accounts and puts those passwords in a text file.

[box]

Convert-MsolDomainToStandard -DomainName {Federated-Domain-Name} -SkipUserConversion $false -PasswordFile c:\password.txt

[/box]

BUT YOU DON’T NEED TO DO THAT!

I need to migrate the same client to ADFS in the near future, so I wanted to investigate what to do if I had a problem in future, “How do I roll back?” and more importantly “How do I limit disruption if theres a problem?

So I built it on the test bench, and did it myself.

Solution

To disable ADFS you need to substitute it for something else, the most common (and easiest) options to work with are ‘Password Hash Synchronisation‘ or ‘Pass-Through Authentication’. I’m going to use password hash synchronisation, but I will also link to pass-through authentication, if you prefer that option.

First job, is to make sure you are on the newest version of Azure AD Connect you can get your hands on. Older versions will not have the options you require. The version you see below was the newest at time of writing.

Then we need to enable password hash synchronisation > Launch Azure AD Connect > Configure > Customise Synchronisation options > Proceed to ‘Optional Features’ > Tick ‘Password Hash Synchronisation’ > Complete the wizard.

WAIT! Let your AD replicate the password hashes, I usually just Force a Delta Azure AD Replication. Then you need to swap from ADFS. Launch Azure AD Connect > Configure > Change user sign-in > Next > Tick “Password Hash Synchronisation’ > Accept the warning > Next.

Note: Yes I saw the warning too, but I had users logged into Outlook etc, and no-one was re-prompted, and no-one was refused authentication. Even so, If you are concerned you might want to do this on a weekend, or after hours.

OK what about ‘Pass-Through Authentication”? If you want a long term scalable ADFS replacement this might be a better option for you, there are some hoops to jump through, and a bit more planning and forethought. See the following article for an explanation;

Azure Pass-through Authentication

Because we are enabling single sign-on, you will be prompted for a set of local domain admin credentials > Complete the wizard.

Then force a Delta Azure AD Replication.

Related Articles, References, Credits, or External Links

NA

Azure Pass-through Authentication

KB ID 0001642

Problem

I’ve never really taken the time to look at pass-through authentication, I set up Azure AAD sync, then I either use ADFS or I don’t. It was only when looking at removing ADFS, that I even looked at it as an option. 

How does Pass-through Authentication Work?

  1. Remote client attempts to authenticate to Office 365 (Azure Active Directory).
  2. Azure queues the request and sends it to an Azure Authentication Agent (on-prem), of which there may be many. Note: The requests will load balance.
  3. The Azure Authentication Agents check the authentication request against the load Active Directory.
  4. The Azure Authentication Agents sends its response back to Azure Active Directory.
  5. The client is authenticated (or denied!)

Why is that Good?

Well you don’t need to deploy ADFS, or WAP. The agent only needs https (outbound) on the firewall Note: If you have a proxy server, theres some URL’s you need to allow. And you don’t need to wait for the default 30 minute AAD replication cycle for changes etc.

Solution

I’m assuming you already have Azure AD sync setup and running, (Simply accept ‘Express settings’ and accept all the defaults), once you have your  local AD replicated to Azure, then you can switch over to pass-through authentication.

Open Azure AS Sync > Configure > Change user sign-in > Proceed to ‘User sign-in’ >pass-through authentication > Finish the wizard.

What happens is the ‘first’ Azure Authentication Agent is installed on the Azure AAD server > Force an AAD Sync > Then look in your Azure Portal > Azure Active Directory > Azure Ad Connect > Pass-through authentication > You should see your first agent.

You can select it and check its details. Note: You can download the Azure Authentication Agent software form this page for you to deploy additional Azure Authentication Agents.

The additional agents are simple to deploy, they will require you to authenticate to Azure though.

They will appear one at a time as deployed.

 

Related Articles, References, Credits, or External Links

NA

Password Sync: No Recent Syncronization

KB ID 0001640

Problem

I recently migrated the server that was running my Azure AD Connector. It was showing no errors post migration so I thought no more about it. A few days later I logged in to Office 365 and saw this;

AAD Connect Status
Azure AD Connect
Password sync: no recent synchronization

Solution

Apparently this can suddenly happen if you are running an old version of AAD Connect. But I checked and mine was brand new, (I’d only just installed it remember). A quick look in the Event Viewer pointed me in the right direction.

Event ID 611

Log Name: Application
Source: Directory Synchronization
Date: xx/xx/xxxx xx:xx:xx
Event ID: 611
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: {server-name}
Description:
Password hash synchronization failed for domain: pnl.com, domain controller hostname: PNL-MGMT.pnl.com, domain controller IP address: 192.168.100.3. Details:
Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices.DrsException: RPC Error 8453 : Replication access was denied. There was an error calling _IDL_DRSGetNCChanges.

 

I’ve highlighted the important part, RPC Error 8453: Replication access was denied. So we have a permissions/rights problem. As I’d set a new user up for the AAD connector software, I checked their rights and found out I was missing the following;

Ensure that the user you are running AAD sync under, has the following permissions on the ‘root’ of your local AD domain.

  • Replicating Directory Changes: Allow
  • Replicating Directory Changes All: Allow

Then I forced an AAD sync, and waited a few minutes, the problem then disappeared.

Related Articles, References, Credits, or External Links

NA

AAD Contains Another Object With The Same DN

KB ID 0001638

Problem

I’ve seen this a few times now, I’ve had users that will not sync from Active Directory to Azure Active Directory (Office 365). When you look to see why, you will see something like;

The Connector {Your-Domain}.onmicrosoft.com – AAD contains another object with the same DN which is already connected to the MV.

Note: For the uninitiated, DN is Distinguished Name, and MV is MetaVerse.

If you attempt to troubleshoot the sync, you may also see something like this;

Object {Distinguished-Name} is not found in AAD Connector Space.

Solution

First we need to temporarily halt the sync;

[box]

Set-ADSyncScheduler -SyncCycleEnabled $False

[/box]

Then launch Sycronization Service Manager > Connectors > Select your AAD Connector > Delete > Delete connector space only > Yes.

Note: Whoa! it says I’m going to lose data, what are we doing? 

Well we are essentially removing all the ‘cached objects associated with this connector, I think about it like ‘flushing the cache’. I’ve never seen this operation break anything, and I’ve certainly never ‘lost’ anything.

While it’s still running, do the same with your local AD connector.

Start the sync scheduler again.

[box]

Set-ADSyncScheduler -SyncCycleEnabled $True

[/box]

Perform a Full Import on your AAD connector..

With the above still running you can repeat a Full Import on your AD Connector 

Providing the full import has finished (i.e the connector says ‘idle’) perform an Export on the AAD Connector.

Providing the full import has finished (i.e, the connector says ‘idle’) perform an Export on the Local AD Connector.

You can then force an AAD sync, and go have a coffee.

Related Articles, References, Credits, or External Links

Azure AD Connect: Correct Or Remove Duplicate Values

The specified module ‘MSOnline’ was not loaded.

KB ID 0001637

Problem

I was trying to do some Azure Powershell this morning, I’d executed a Connect-MsolService command and got a;

The term ‘Connect-MsolService’, function, script file, or operable program.

A quick Google for that turned up ‘You need to run an Import-Module MSOnline‘ command, but doing that simply gave me;

[box]

PS C:\Users> Import-Module MSOnline
Import-Module : The specified module 'MSOnline' was not loaded because no valid module file was found in any module
directory.
At line:1 char:1
+ Import-Module MSOnline
+ ~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ResourceUnavailable: (MSOnline:String) [Import-Module], FileNotFoundException
    + FullyQualifiedErrorId : Modules_ModuleNotFound,Microsoft.PowerShell.Commands.ImportModuleCommand

[/box]

Solution

Well before you can run Import-Module MSOnline, run Install-Module MSOnline, you may need to answer ‘Y’ to proceed.

Then, run Import-Module MSOnline and you are good to go!

Related Articles, References, Credits, or External Links

NA