Platforms, Lync, the Cloud, Oh My!

Common problems related to using third-party IDPs with Azure and Office365

Jeffrey Harness — Fri, 04 May 2018 17:11:50 GMT

Hello again Technet community! Over the span of the last year or so, I've been assisting quite a few customers with integrating Azure and Office 365 services into on-premises environments. Many of these customers have adopted our unique hybrid topology, and are running a combination of our cloud services right alongside on premises based services. As many of you undoubtedly know, hybrid service implementations are heavily reliant on a rock solid identity strategy. While there are many solutions that customers can adopt for identity, this blog is going to focus heavily on customers that have chosen to adopt federation based strategies. Specifically, we're going to be focusing on identity strategies that revolve around utilizing third-party (non-ADFS) services and solutions for federated identity... services such as Tivoli, Siteminder, etc. This article will not focus on the implementation aspect of getting these service to play nice with your Office 365 and Azure environments, rather, we're going to focus on some nuances you may or may not encounter while working with these services. So without further ado, lets jump right into the lessons learned! Problem: I'm using a third-party IDP (non-ADFS) for federation, and I need to make a federation configuration change within my tenant. Every time I run the set-msoldomainfederationsettings cmdlet to update my configuration, I receive a "Invalid value for parameter" error. I know why syntax is correct! What's going on?!? Error example

Set-MsolDomainFederationSettings : Invalid value for parameter. Parameter Name: .

At line:1 char:1

+ Set-MsolDomainFederationSettings -DomainName "contoso.com" -ActiveLogOnUri "https:// ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : OperationStopped: (:) [Set-MsolDomainFederationSettings], MicrosoftOnlineException

+ FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.PropertyValidationException,Microsoft.Online.

Administration.Automation.SetDomainFederationSettings

Solution: This particular error took a bit of digging as well as trial and error in a lab environment to figure out! The customer that was receiving this error was using a third-party federation solution that was configured to use SAML as the sign-in protocol. As it turns out, the set-msoldomainfederationsettings cmdlet only lets you modify the configuration of IDP's that are utilizing the WS-FED sign-in protocol, which is the default protocol used by ADFS when you initially configure the service. So how does one update their tenant federation configuration when using a SAML based provider? The easiest way to work around the error is to revert the federated domain your working with back to a managed domain within Azure Active Directory, and the re-federate the namespace with the appropriate configuration settings. Here are the steps you would need to follow:

Revert your federated domain back to managed domain by running: Set-MsolDomainAuthentication -DomainName contoso.com -Authentication managed
Federate your domain again by running: Set-MsolDomainAuthentication.

To speed the process up, I recommend performing these steps via script. Here's an example of a script that will do the trick:

Set-MsolDomainAuthentication -DomainName contoso.com -Authentication managed

$domainName = “contoso.com”

$brandName = “Some name here!”

$logonUrl = "https://lab.contoso.com/acu/Office365"

$issuerIUri = "https://lab.contoso.com/acu/sps/Office365/saml20"

$logoffUri = "https://lab.contoso.com/acu/sps/Office365/saml20/slo"

$cert = "Your base64 cert string here!"

Set-MsolDomainAuthentication -DomainName $domainName -PassiveLogOnUri $logonUrl -ActiveLogOnUri $logonUrl -IssuerUri `

$issuerIUri -SigningCertificate $cert -LogOffUri $logoffUri ` -Authentication "federated" -PreferredAuthenticationProtocol SAMLP `

-FederationBrandName $brandName

If you script the process using your own script or the code mentioned above, the entire configuration change takes about two seconds. Please bear in mind that the configuration change can sometimes take up to ten minutes to go into effect on the back-end side of AAD... so please plan accordingly and do not perform configuration changes during the work day when you have active users!

The Pitfalls of Using Multiple Patch Management Services on Windows 10

Jeffrey Harness — Mon, 23 Oct 2017 19:59:02 GMT

Hello again fellow Windows 10 users! I'd like to dedicate this post to discussing a reoccurring problem that I am seeing crop up in more and more customer environments, where multiple patching services (such as MS System Center Configuration Manager and IBM Bigfix) are being utilized concurrently to facilitate the patching of Windows 10 devices. The use of two different patching solutions within the same environment can lead to a very unique situation being encountered where Windows 10 will not initialize the OS properly, leading to users getting stranded in the Windows Recovery Environment. The back story. To really get to the bottom of what's happening, you need to be familiar with the patching methodology that Microsoft is utilizing to ensure that Windows 10 stays as up to date as possible. When Windows 10 became generally available to the public, a new patching paradigm was adopted to keep the code that Windows 10 runs off of as up to date and secure as possible for all of our customers. Monthly Cumulative Updates (referred to as CUs from this point on) became the new patching mechanism responsible for delivering all the necessary code changes to the Operating System. Anyone who has ever worked with CUs knows that there is one predominant problem when it comes to CUs... mainly that they are, well, cumulative! Each months update gets progressively larger because of ever increasing amounts of updated code that get added to the updates. To combat the growth problem, shortly after the release of Windows 10 version 1607 (Anniversary Update), Microsoft introduced a new Windows Update package type effectively dubbed the Delta update. Like the name implies, it only contains code that has changed since the last full CU that was released, which effectively (and dramatically) reduces the overall size of the updates that get pushed out to managed systems. Cool right? Unfortunately, these two patch types have introduced some peculiar issues into customer environments... especially environments that rely on two different patch deployment solutions. The problem. The main problem that arises from utilizing multiple patch deployment services is that it becomes possible to potentially deploy both types of updates concurrently. When it comes to the issue mentioned in the first paragraph of this article, this is in fact exactly what's happening, which is typically what leads to Windows 10 devices ending up a non-bootable condition. The problem state occurs when both a full CU and Delta CU get deployed during the same reboot cycle from both patch management solutions. Picture this scenario if you will. Your organization utilizes IBM Bigfix to catch and deploy the full CU out to all Windows 10 machines that need it, and MS System Center Configuration Manager to deploy the Delta updates. A Windows 10 machine that is a month or so behind on it's updates gets booted up and analyzed by both services. BigFix sees that the device needs the latest deployed monthly CU, and pushes the update down to the system. No restart occurs due to policies that are in place that prevent this kind of action from occurring during work hours. The Configuration Manager Agent kicks in directly afterwards, and detects that the machine needs the latest Delta update that has been published. This update gets pushed down to the system and installed. No restart occurs due to the same policies mentioned above. When the machine does finally reboot, we immediately encounter the non-bootable state mentioned above. So why is this? Lets dig into the issue a bit. If we take a look at the stop error code that gets generated by the system during startup, we will see that a 0x7B INACCESSIBLE_BOOT_DEVICE stop error code gets thrown. This error is a direct result of the oddball boot state that the system gets into when both a full CU and Delta update get pushed to, and installed by a system during the same reboot cycle. Recovery. So great. You've found yourself stuck in this state. Now what? Fortunately, it's fairly easy to recover Windows 10 devices from this non-bootable condition. Unfortunately, the use of Bitlocker or other third-party encryption service like McAfee or CheckPoint tend to slightly complicate the recovery process. You will quickly find that you need to decrypt or suspend encryption on these system prior to being able to perform the recommended fix action below. For Bitlocker users, suspending encryption is a fairly straight forward and easy process. Use the following commands below to suspend encryption so that the repair operation can be performed: manage-bde.exe -protectors -get c: manage-bde.exe -unlock c: -recoverypassword "xxxxxx" manage-bde.exe -protectors -disable c: In the case of other third party encryption solutions, I've seen the decryption process take anywhere from a couple of hours, to three or four days... depending on the encryption service that's being utilized. If a customer has a wealth of data that has not been backed up on their system, it will likely be a very worthwhile action for you to perform. The reason the device needs to be either decrypted or unlocked is due to the fact that we will need to utilize some recovery tools from the nifty Windows Recovery Environment that will need access to the volume that Windows is installed on... namely, the Command Prompt, which can be found under the Advanced Options section of the Recovery Environment: Once you have gotten into the Command Prompt, you're going to want to run the following command:

dism.exe -image:C:\ /get-packages > X:\packages.txt

*Note - The -image option should point to the volume where the Windows directory is located.

Open the packages text file with notepad by typing: notepad x:\packages.txt

At this point you will want to scroll all the way to the bottom of the text file, and look for any packages that have a state status of Install Pending. Copy the package names, and use the following command to remove the 'Install Pending' packages:

dism.exe /image:C:\ /remove-package /packagename:Package_for_RollupFix~31bf3856ad364e35~amd64~~14393.953.1.2

*Note - The above package name was included only as an example. Please ensure you use the package name from the packages.txt file above. Once the DISM tool has finished removing the package, your system should be good to go. Once it's reboots, Windows 10 will continue to uninstall any packages previously scheduled for removal, at which point the OS should be able to initialize itself properly. The follow up. To prevent the non-bootable issue from reoccurring in the future, it is highly recommended that customers configure their patching infrastructure so that the Windows 10 full CUs and Delta updates are NOT installed at the same time, during the same reboot cycle. And there you have it folks! Go forth and perform good updating deeds! Until next time.

Disabling Windows 10 Notifications via Group Policy

Jeffrey Harness — Fri, 05 May 2017 21:46:42 GMT

****This procedure only works in Windows 10 build 1607 and above!**** Hello there fellow Windows 10 users! A question that I get asked frequently by customers who are deploying Windows 10 these days is whether or not it's possible to disable specific notifications within the Action Center. The reasons for wanting to do this are many, but the most common reason is because a customer has decided to utilize a third-party security suite on their system, and they have turned off the Security Center service to keep the OS from repeatedly warning them that the Fire Wall profiles have been turned off, the Windows Defender service has been turned off, etc. Unfortunately, the OS really wants you to keep the Security Center service turned on (for good reason!), so it will periodically remind you that the service has been stopped, and recommend that you turn it back on within the Action Center. My recommendation has always been to ensure that you are using a security product that uses our COM API's to play nice with Security Center, but some super secure organizations still turn it off and rely on other security software that's installed on the Operating System. So there is our dilemma! Prior to the release of Windows build 1607 (a.k.a. the Anniversary build), it was not possible to selectively disable specific notifications from popping up within the Action Center. While Windows 7 used to have some notification registry keys for the Security Center that you could tinker with to turn off the notifications, those settings did not carry through to Windows 8/8.1/10. The 1511 and earlier builds of Windows 10 would allow you to disable SOME notifications from firing and ending up in the Action Center, but not all. In builds of Windows 10 prior to 1607, if you wanted to disable the Security Center (and may other) warnings from appearing within the Action Center, you're only option was to turn on a local or group policy setting that essentially turns off ALL notifications that may appear within the Action Center. As you may have guessed, this approach really stunk because it prohibited you from receiving other useful notifications from applications that you may have wanted to receive notifications from... like the built-in email application, and notifications from Outlook! Luckily, notification behavior appears to have changed significantly starting with Windows 10 build 1607. I say "appears" because I stumbled across the new behavior while performing process traces for a completely unrelated issue that I was troubleshooting! I have yet to find any documentation that refers to these changes, but the behavior has definitely changed in the favor of customers who wish to have the ability to selectively disable specific notifications across the board for all users. So how does this new behavior help us selectively disable notifications? I'm glad you asked! Windows 10 build 1607 and above appears to now store the notification configuration data for each user within the following registry key: HKCU\Software\Microsoft\Windows\CurrentVersion\Notifications\Settings. When a notification is disabled, an Enabled DWORD registry value is created within a corresponding child key, with a value set to 0. If you've ever taken a look at the notifications settings within Windows 10, you've undoubtedly seen that there are numerous built-in services and applications that we can disable notifications on, and each one of those services and applications has it's own string that the OS recognizes. Now I bet you're thinking that it would sure be nice of me to list all of these keys. Don't worry, I will below. But I can also offer you something that's potentially better, depending on how you'd like to deploy these settings. I recently worked on a Windows 10 deployment project with a customer who wished to turn off most of the default built-in notifications. They also didn't want to do it via preferences (long story). So what I ended up doing is creating a custom ADMX template for them that allowed their administrators to turn on and off the notifications for all users at will. A download link for the template files can be found at the bottom of this article. When the template is imported into either the local or Central policy store, you end up with an additional User Configuration\Administrative Templates\Windows Components GPO category that looks like this: ****This part is important!**** Those of you with a keen eye may have noticed that the policy settings look a bit different from other policy settings that you can define within gpedit or GPMC. There's a reason for this, and it's a reason that you need to bear in mind for any future changes that you make! The policy settings that my ADMX file lets you define are NOT managed policy settings, as the registry values that the policy creates are not located in any of the managed SOFTWARE\Policies registry keys. This means that the registry values that the ADMX file creates are considered to be preferences (different from GPP slightly), which makes sense considering that these values are usually set on a per-user basis. As of the time of the writing of this article, the notification subsystem in Windows 10 does not appear to support managed registry values, as it completely ignores any registry values that we add to HKCU\SOFTWARE\Policies key. So what does this mean if you chose to use the ADMX file to disable the notifications? It means that any notification that you chose to disable will STAY disabled, even if the Group Policy Object that you've created is unlinked from the system that it's applying too. If you wish to re-enable a particular notification, you'll have to do one of two things:

If the GPO is still applying to your systems, you can easily re-enable the notification by simply modifying the above GPO settings and selecting the 'Disabled' option. This option changes the Enabled 0 value to a 1, which causes the OS to ignore the setting and enable the notification.

If you have unlinked the policy from a system and wish to enable the notification, you'll either have to manually remove the associated registry key, or simply go into the Notifications section of the Settings app and turn the notification back on.

For those of you who don't mind creating a Group Policy Preference GPO, you could also disable the notifications by simply adding any of the below registry keys and values to your policy, and then linking the policy to the users that you wish to disable the notifications on. Since the registry keys and values that we are putting in place are considered to be preferences so far as the OS is concerned, it only makes sense to deploy the registry keys and values using GPP! If you don't need the visual cues that are provided by the ADMX file, then this method is for you. Here are the keys and the values that will allow you to disable notifications from most of the built-in apps and services in Windows 10: Disable Security and Maintenance Notifications HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Notifications\Settings\Windows.SystemToast.SecurityAndMaintenance\Enabled = 0 (DWORD) Disable OneDrive Notifications HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Notifications\Settings\Microsoft.SkyDrive.Desktop\Enabled = 0 (DWORD) Disable Photos Notifications HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Notifications\Settings\Microsoft.Windows.Photos_8wekyb3d8bbwe!App\Enabled = 0 (DWORD) Disable Store Notifications HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Notifications\Settings\Microsoft.WindowsStore_8wekyb3d8bbwe!App\Enabled = 0 (DWORD) Disable Suggested Notifications HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Notifications\Settings\Windows.SystemToast.Suggested\Enabled = 0 (DWORD) Disable Calendar Notifications HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Notifications\Settings\microsoft.windowscommunicationsapps_8wekyb3d8bbwe!microsoft.windowslive.calendar\Enabled=0 (DWORD) Disable Cortana Notifications HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Notifications\Settings\Microsoft.Windows.Cortana_cw5n1h2txyewy!CortanaUI\Enabled=0 (DWORD) Disable Mail Notifications: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Notifications\Settings\microsoft.windowscommunicationsapps_8wekyb3d8bbwe!microsoft.windowslive.mail\Enabled=0 (DWORD) Disable Edge Notifications HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Notifications\Settings\Microsoft.MicrosoftEdge_8wekyb3d8bbwe!MicrosoftEdge\Enabled = 0 (DWORD) Disable Audio Notifications HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Notifications\Settings\Windows.SystemToast.AudioTroubleshooter\Enabled = 0 (DWORD) Disable Autoplay Notifications HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Notifications\Settings\Windows.SystemToast.AutoPlay\Enabled = 0 (DWORD) Disable Battery Saver Notifications HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Notifications\Settings\Windows.SystemToast.BackgroundAccess\Enabled = 0 (DWORD) Disable Bitlocker Notifications HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Notifications\Settings\Windows.SystemToast.BdeUnlock\Enabled = 0 (DWORD) Disable News Notifications HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Notifications\Settings\Microsoft.BingNews_8wekyb3d8bbwe!AppexNews\Enabled = 0 (DWORD) Disable Settings Notifications HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Notifications\Settings\windows.immersivecontrolpanel_cw5n1h2txyewy!microsoft.windows.immersivecontrolpanel\Enabled = 0 (DWORD) Disable Tablet Notifications HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Notifications\Settings\Windows.System.Continuum\Enabled = 0 (DWORD) Disable VPN Notifications HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Notifications\Settings\Windows.SystemToast.RasToastNotifier\Enabled = 0 (DWORD) Disable Windows Hello Notifications HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Notifications\Settings\Windows.SystemToast.HelloFace\Enabled = 0 (DWORD) Disable Wireless Notifications HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Notifications\Settings\Windows.SystemToast.WiFiNetworkManager\Enabled = 0 (DWORD) That about sums it up people! Now go out and disable notifications to you or your customer's hearts content! Until next time! windows-10-notifications-admx_adml

Where did my P2V go?!?

Jeffrey Harness — Thu, 20 Nov 2014 12:29:14 GMT

Has your recent upgrade from SCVMM 2007/2007 R2 to SCVMM 2012/2012 R2 left you scratching your head when looking for the option to convert a physical machine to a virtual machine (P2V)? If so, you're not alone, and you're definitely not crazy! P2V functionality was purposely left out of the newer 2012 versions of Virtual Machine Manager, as it allowed our development teams to concentrate on improving the fabric, storage, and network components that are built into SCVMM. Shortly after the release of SCVMM 2012, we released a tool called the Microsoft Virtual Machine Converter tool, which gave our customers the ability to convert VMWare ESX based VMs to Hyper-V VMs, however it lacked the more useful P2V functionality that was built into SCVMM 2007/2007 R2. Fortunately for us, the development team responsible for the creation of the tool has been hard at work getting P2V functionality implemented back into the toolset. If this is something that you have been patiently (or impatiently... you know who you are!) waiting for, then today is your lucky day! Hot off of the MS data presses as of this morning, the new version of the tool that includes core P2V functionality has been released, and can be downloaded here: Microsoft Virtual Machine Converter 3.0 Enjoy!