Blog

I've run into this issue a few times over the past few months and the fix has been roughly the same each time. Typically, what will happen is that a user account is created in Azure AD with a specific username/UPN. Later on, an account will be synced from the on-premise Active Directory environment with the same username/UPN. Azure tries to automatically reconcile this during the sync by renaming the synced account and appending numbers to the end.

Naturally, this is a problem if you need the on-premise AD account to be the authoritative copy. The first thing to be resolved is whatever is causing the conflict in the first place. Once that is resolved, Azure won't automatically rename everything back. Not to mention that once the account is already synced, it won't auto update the account as the source has not been changed since the original sync.

Since deleting and re-creating the on-premise account isn't always the best option, your solution is fairly simple – update the attribute on the source side to some bogus value, force a delta sync, update the attribute back, and force a delta sync again.

For example, if the email address of your on-premise user is tuser@domain.com and the Azure AD account shows the SMTP attribute is listed as tuser5589@domain.com, update the primary SMTP value in the proxyAddresses attribute to tuser1@domain.com and force a delta sync. Azure AD should then show tuser1 as the primary SMTP value with tuser5589 no longer listed. Once you see that, change it back to tuser@domain.com and force another delta sync.

I've had to run through similar steps with the proxyAddresses and the UPN attributes for the conflicting objects.


 

We have a customer that I'm working with to rebuild their RDS farm from 2008R2 servers to 2016. Once I finished the initial deployment, I began testing the builds and realized pretty quickly that I couldn't open the start menu or use even use the search feature in the taskbar no matter what I tried.

I was using the same group policies that were currently applied on their existing farm thinking it should transition pretty smoothly, but that turned out not to be the case. I was eventually able to narrow it down to a single policy, but I also made the mistake of using Group Policy Management from their current 2008R2 management server, which I discovered later on complicated the troubleshooting since the setting causing the issue isn't visible from the 2008R2 console.

It ultimately turned out to be due to Applocker's Packaged App Rules. Since this had never been configured previously, there was no default rule to allow signed packaged apps that had been introduced in Server 2012 and later, and is what was ultimately breaking the Start button/Search feature.


 

My home Surface Mini running Windows 10 would default to Pacific time zone instead of Central. I would change the time zone, but when the system was rebooted it would default back to Pacific. One place where you change the time zone we would get an "Unable to continue" error. After trying a few things, I attempted using the command prompt to change the time zone & it worked. Here are the time zone commands you can use:

  • "tzutil /g" will show you the current time zone.
  • "tzutil /l" will give you a list of possible time zones.
  • "tzutil /s "name of time zone"" will allow you to set a time zone, (i.e. tzutil /s "Central Standard Time"}

 

I had a customer who had several users who could not do any searching in Outlook. The error was, "Something went wrong and your search couldn't be completed." along with a mention of the appearance of there being no network connection.

Another engineer had been talking with one of the customer's IT people about a different issue and apparently they may have accidently turned off EWS (Exchange Web Services) globally while investigating/troubleshooting another problem. I compared the broken mailbox to a known working mailbox and the working mailbox had EWS enabled, so I re-enabled it using some Powershell commands and the user was now able to search. 

To check if EWS is enabled/disabled - get-casmailbox someMailbox@domain.com | fl *ews*

To turn on EWS on for Outlook - Set-CASMailbox someMailbox@domain.com -EWSEnabled $true -EWSAllowOutlook $true

https://docs.microsoft.com/en-us/powershell/module/exchange/client-access/set-casmailbox?view=exchange-ps

Exchange Web Services is typically on by default for Outlook as it is used for a variety of functions including searching, calendar shares, permissions and availability, shared mailbox permissions, and out of office settings.


 

After changing my domain password, the Microsoft Teams app on my iPhone signed me out, and I was unable to sign back in. When I would enter my username & password, it would go to a white screen with a spinning circle for several minutes and eventually time out. After trying several things I finally wondered if some of my content/privacy restrictions might be causing the problem & sure enough that was the case.

When I disabled the web content filter it worked. To configure this setting on an iPhone with iOS 13.x, go to Settings > Screen Time > Content & Privacy Restrictions > Content Restrictions > Web Content and set it to "Unrestricted Access"


 

I wanted to be able to install some software on a personal Microsoft Surface, but when I went to switch Windows out of S mode, the "Get" button was grayed out.

This can happen if you are not an Administrator on the machine or if the machine is associated with a domain; however, neither of these were the case. The issue for this device was it had an associated school account. To fix the problem and allow you to get out of S mode, follow these steps:

  1. Open Windows settings.
  2. Select Accounts.
  3. Click on the Access work or School tab on the left-hand side.
  4. Click on the businesses account (school or work), then click on Disconnect or Remove. Removing these accounts will not actually remove your organization email from individual apps, but these kinds of accounts can have automatic restrictions associated with them which would limit things like switching out of S mode.
  5. Reopen the Microsoft Store and you should now be able to Get out of S mode.
  6. Re-add the associated accounts if needed.

 

A customer was setting up Bitlocker encryption on laptops so that they could be checked out of the office. They wanted to have Bitlocker startup keys created on one removable flash drive and then be able to copy the required key to another flash drive. When a user needed to check out a laptop, they would also be given a flash drive to be able to start up any of the laptops with Bitlocker.

The customer was saving the startup keys correctly through BitLocker, but could not see them on the removable flash drive through Windows Explorer. Although they had "show hidden files" enabled, they needed to uncheck the view options for "Hide protected operating system files". This allowed the customer to see the startup keys to be able to copy to other removable flash drives.


 

I ran across an issue where I was trying to delete a file and kept getting several errors while attempting to delete said file.

1. Permissions issue --- Received an error that I needed permission from File owner to be able to delete. I made myself the owner of the file and attempted to delete the file. That introduced error #2 listed below.
2. Directory is not Empty --- After resolving the permissions issue I began to receive an error that indicated the folder was not empty "Cannot Delete folder: The directory is not empty". So I went into make sure 'view hidden files' was checked in file explorer and it already was, yet the file in question still showed to be empty when opening it. Did some research and discovered that you can change the search options to include all subfolders and also to allow searching for files that are 'Empty' see screenshot below. After searching in this manner I was able to view a ton of subfolders that were sometimes 4 or 5 levels deep, and inside of those deeper folders, there would be data, which introduced error #3 to follow.

3. Filename too long --- The final error I was receiving indicated that the filename was too long. "The file name(s) would be too long for the destination folder…" This is the result of embedded file paths that end up surpassing the 255 character limit. Typically what you'll come across is filename\filename\filename\filename\filename\filename\filename or you might see filename\filename\realllyyyllllonnngggfilename\. Some suggestions for fixing this are to find one of the directories that seem to include the long string of characters and rename the folder. That didn't always work. 

A more common suggestion is to navigate a good way into the long directory path (filename\filename\filename\filename\filename\filename\filename) and then share out one of the folders. Map to the newly shared folder and then delete everything inside. After that you should be able to delete this directory itself, and the root directory that this folder lives in. This solution was actually working, but with so many files to navigate through, this was very time consuming and not really practical for my situation.

What I ended up using as the actual solution was a robocopy script with the /purge switch. Basically you create an empty folder somewhere, and use that as the source folder during the robocopy. Script will end up looking like this:
Robocopy EmptyFolderPath FolderToDeletePath /purge
Robocopy will cycle through and purge, or delete anything in the destination folder that is NOT in the source folder. Since the source folder in this case is empty, all files will be deleted. Please note you will need to run this through and elevated cmd prompt.


 

During my first attempt at installing the Office suite through O365, I began running into issues with the 'Invalid Security Certificate' warning popping up every few minutes after setting up the associates Outlook profile. This customer already had the proper GPO in place set to disable SCP look up, exclude httpautodiscoverdomain, etc, which had been effective at stopping this from occurring in the past with your standard Office install. After updating the ADMX files (which include a number of new Autodiscover policies) to the latest set in hopes of resolving the issue, the issue with the certificate warning continued to surface every few minutes. After doing some reading, I discovered there are two registry hives that can manage Autodiscover:
Computer\HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Autodiscover
Computer\HKEY_CURRENT_USER\Software\Policies\Microsoft\office\16.0\outlook\autodiscover

The latter Policies hive is where the key changes take place when managing via GPO, which was not performing the intended way with this O365 setup. I manually tested adding the Excludehttpautodiscoverdomain key to the first hive, and the security warnings stopped immediately. I tested disabling and enabling keys in both hives, and was able to confirm the finding. I have not had an opportunity to see if this issue exists for any other workstation/customer, but hopefully someone might find this useful if they do. I wound up just adding this key in via the registry via GPO and had no further issues after it was applied.


 

One of our customers is hosting their servers with a hosting provider who also provides some other servers, like backups and patching. The hosting provider was unable to patch some of the servers for this customer. After investigating with the hosting provider, it was determined that they could patch all of the servers except for the domain controllers. The service account they were using was a Domain Admin so it should have been able to patch any server. I logged into another server as the service account and tried to access the admin$ share on one of the domain controllers, but was unable to do so.

After some investigation, I found that the Domain Admins group was not a member of the built-in Administrators group in Active Directory. The customer had removed the groups from the Administrators group and had manually put accounts in that group when necessary. This caused the service account the hosting provider was using to work on all of the member servers because Domain Admins had administrative rights to those servers, but they were unable to access the domain controllers because the service account was not an administrator on the domain controllers since it was not a member of the Administrators group. I am not sure why the customer removed the default groups from the Administrators group, so I just added the service account to the built-in Administrators group. The hosting provider attempted to patch the servers again and verified it was working properly.