bcTechNet http://www.bctechnet.com Awesomeness lives here... Fri, 16 Nov 2018 14:41:04 +0000 en-US hourly 1 https://wordpress.org/?v=5.1.2 19561816 ConfigMgr and Microsoft Store for Business Sync Fails /configmgr-and-microsoft-store-for-business-sync-fails/ /configmgr-and-microsoft-store-for-business-sync-fails/#respond Tue, 29 May 2018 14:55:44 +0000 /?p=600 I ran into a odd problem when trying to setup the connection between Configuration Manager and the Microsoft Store for Business. I completed all steps mentioned at: https://docs.microsoft.com/en-us/sccm/apps/deploy-use/manage-apps-from-the-windows-store-for-business, however the sync would fail. In the WsfbSyncWorker.log I found this error: System.IO.IOException: This security ID may not be assigned as the owner of this object.

This error made it sound like there was a permission issue. However, after much troubleshooting, it was determined not to be the problem.

The actual problem was Content Location for the Microsoft Store for Business sync object. We were originally using the same DFS path that all of our other ConfigMgr source content uses. Apparently there is a bug or this is not supported. We then created a new share on the Primary Site ConfigMgr server and set the Content location for Microsoft Store for Business in ConfigMgr to this path and then the sync worked.

 

]]>
/configmgr-and-microsoft-store-for-business-sync-fails/feed/ 0 600
SCVMM 1801 Upgrade Fails /scvmm-1801-upgrade-fails/ /scvmm-1801-upgrade-fails/#comments Fri, 09 Mar 2018 17:24:52 +0000 /?p=593 When going through the upgrade process, I got a failure when install the upgraded Management Server.

After digging through the setup logs (C:\ProgramData\VMMLogs), I found this in the SetupWizard log file: Violation of PRIMARY KEY constraint ‘PK_tbl_NetMan_PortClassification’. Cannot insert duplicate key in object ‘dbo.tbl_NetMan_PortClassification’. The duplicate key value is (<ID>).

After some investigation, I found a brief mention of this in the 1801 release notes. It states if any of the default port classifications have been renamed, the upgrade will fail. The release notes just mention that it is required to rename these back to their default values, but doesn’t tell you what these values are . In my case it was the “Live migration  workload” port classification. The default for some reason has two spaces between “migration” and port”. Sometime in the past, we had removed this extra space. Adding the space back in resolved the issue.

You can determine which port classification is the culprit by comparing the ID in the logs to the ID in the tbl_NetMan_PortClassification table in the VMM database. If the old VMM Management server is no longer online, you will have to manually update the Name in the tbl_NetMan_PortClassification table in the VMM database to fix this.

In case your failure is for a different classification, here are all the default port classifications:

  • SR-IOV
  • Host management
  • Network load balancing
  • Guest Dynamic IP
  • Live migration  workload
  • Medium bandwidth
  • Host Cluster Workload
  • Low bandwidth
  • High bandwidth
  • iSCSI workload
]]>
/scvmm-1801-upgrade-fails/feed/ 1 593
High CPU on IIS Server 2016 from MsMpEng.exe /high-cpu-on-iis-server-2016-from-msmpeng-exe/ /high-cpu-on-iis-server-2016-from-msmpeng-exe/#comments Wed, 29 Mar 2017 16:25:03 +0000 /?p=568 If you are running production load on an IIS server that is also running Windows Server 2016 and you are running Windows Defender/Endpoint Protection with Real-Time Protection enabled on this server; you may find that MsMpEng.exe (Windows Antimalware service) is taking a lot of CPU and causing IIS performance issues.

Fortunately the solution is relatively simple. After some trial and error, I was able to find that the Real-Time Protection setting: “Scan all downloaded files and enable exploit protection for Internet Explorer” was the culprit. Simply changing this setting to “No” immediately solved the problem.

I have found this setting does not appear to cause issues in Windows Server 2008 R2, 2012 or 2012 R2, only 2016. Also, in Server 2016, this setting is not exposed via the UI on the server and must be managed via System Center Configuration Manager (or manually edit the registry).

I did not notice an issue on IIS servers with low load (as Windows Defender could keep up), but once started having hundreds/thousands of connections to the IIS server, MsMpEng.exe (the Windows Antimalware service) would immediately peg CPU to 100%.

]]>
/high-cpu-on-iis-server-2016-from-msmpeng-exe/feed/ 4 568
Windows Sysprepped Machine Fails to Automatically Register with Azure /windows-sysprepped-machine-fails-to-automatically-register-with-azure/ /windows-sysprepped-machine-fails-to-automatically-register-with-azure/#comments Wed, 15 Feb 2017 15:13:38 +0000 /?p=560 Beginning with Windows 10 1511, Windows based computers will attempt to automatically register with Azure Active Directory. For this to succeed some configuration is required (I won’t go into this detail, but you can find official steps here: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-conditional-access-automatic-device-registration-setup).

I found that even when following these steps, the DRS process still wasn’t working for me. To diagnostic this, you can look at the Windows Event Log at: Application and Services\Microsoft\Windows\User Device Registration\Admin. In my logs was this error: Automatic registration failed at join phase.  Exit code: Keyset does not exist. Server error: empty.
Note: You can also diagnose this by running a command prompt as SYSTEM account (use psexec -i -s cmd.exe) and running dsregcmd /debug and dsregcmd /status.

During troubleshooting, we found that any machine that had a TPM or a machine that was built directly off the Windows 10 ISO worked. Any machine that was a VM (or physical with no TPM), that was imaged using SCCM failed with the above error.

After some great support from the MS product team, we discovered the reason for this error. When there is no TPM present, Crypto files are stored here: C:\ProgramData\Microsoft\Crypto\Keys. There is a special key that is used by Azure DRS, it always begins with: f9890073e78468741a6bc490ab388f59_<unique GUID here>. What we discovered is that there is an issue with the sysprep process not clearing these crypto keys like it is supposed to, and this causes Azure DRS to fail.

Fortunately, until MS is able to fix the sysprep bug, the fix/workaround is fairly simple. Simply delete the Crypto key that begins with “f9890073e78468741a6bc490ab388f59“. Once deleted, the next time Azure DRS runs, a new key file will be created (as well as others) and DRS will succeed.
Note: To force DRS, you can simply log out and log back in and wait 1 minute, or you can run the Automatic-Device-Join scheduled task in the Workplace join folder, or you can use a SYSTEM command prompt to run dsregcmd /join.
Note 2: In order for user state DRS to complete, machine DRS must first be completed; then the machine must be locked and unlocked at least once to trigger user DRS with Azure.
Note 3: You can validate this from a regular user command prompt and running dsregcmd /status. For machine registration, look for AzureAdJoined set to Yes. For user registration look for WamDefaultSet set to Yes and AzureAdPrt set to Yes. If all this is true, then Azure DRS should be completed successfully.

In my case, I had several images and hundreds of machines affected by this issue. To fix , I first repaired my images. This can be done by using dism tool to mount the image, delete the bad Crypto file, then commit changes to the WIM. Details steps can be found here: https://msdn.microsoft.com/en-us/windows/hardware/commercialize/manufacture/desktop/mount-and-modify-a-windows-image-using-dism.  Secondly, to fix my existing machines, I used a simple PowerShell script, that I executed with SCCM, to find the bad key file and delete it. Here is the script for your convenience. (Note: The date check in the script is used to protect from deleting good keys from working machines. I matched the date time to the bad keys in the sysprepped image that was used to deploy these machines).

# Set Variables
$DateToCheck = Get-Date -Month 12 -Day 1 -Year 2016
Set-Location “C:\ProgramData\Microsoft\Crypto\Keys”

# Find File
$DRSCryptoFile = Get-Item * | where { $_.Name -like “f9890073e78468741a6bc490ab388f59_*” }

 # If File found and old, then remove (system will regenerate)
if (($DRSCryptoFile -ne $null) -and ($DRSCryptoFile.LastWriteTime -lt $DateToCheck))
{
    Remove-Item $DRSCryptoFile -Force -Confirm:$false
}

Note: When using SCCM to deploy, I had to use SysNative path for PowerShell for the script to run properly (needed x64 context): %systemroot%\sysnative\windowspowershell\v1.0\powershell.exe -NoProfile -File “Script.ps1”

]]>
/windows-sysprepped-machine-fails-to-automatically-register-with-azure/feed/ 1 560
RDS Health Monitor in F5 for Windows Server 2016 /rds-health-monitor-in-f5-for-windows-server-2016/ /rds-health-monitor-in-f5-for-windows-server-2016/#comments Wed, 09 Nov 2016 20:09:54 +0000 /?p=557 When rolling out new servers for Remote Desktop Services in Windows Server 2016, that are load balanced with F5 (Connection Broker servers specifically), I found that the Send/Receive strings used for the Health Monitors in F5 that we used for Windows Server 2012 R2 did not work in Windows Server 2016. After diving into some diagnostics logs, it looks like the response string has changed in Windows Server 2016. 

Here are the Send/Receive strings for both the old 20012 R2 and the new 2016 that worked for me:

Send String: \x03\x00\x00\x13\x0E\xE0\x00\x00\x00\x00\x00\x01\x00\x08\x00\x0b\x00\x00\x00
Receive String (2012 R2): \x03\x00\x00\x13\x0E\xD0\x00\x00\x12\x34\x00\x02\x0f\x08\x00\x08\x00\x00\x00
Receive String (2016): \x03\x00\x00\x13\x0e\xd0\x00\x00\x124\x00\x02\x1f\x08\x00\x08\x00\x00\x00

]]>
/rds-health-monitor-in-f5-for-windows-server-2016/feed/ 2 557
ADFS: Raise Farm Behavior Level Issue /adfs-raise-farm-behavior-level-issue/ /adfs-raise-farm-behavior-level-issue/#comments Tue, 18 Oct 2016 22:37:05 +0000 /?p=551 After upgrading our ADFS servers to Windows Server 2016, the last step was to raise the Farm Behavior Level using the Invoke-AdfsFarmBehaviorLevelRaise PowerShell cmdlet. In my case, when I ran this command, I received the following error:

Invoke-AdfsFarmBehaviorLevelRaise : Database upgrade could not be performed on localhost. Error: Unable to connect to
the database. You may not have permission to create the AD FS configuration database in the specified SQL server. You
can do one of the following: (1) have the SQL administrator grant permissions to you to create the AD FS configuration
database in the specified SQL server or (2) have the SQL administrator create the AD FS configuration database by
running  SQL scripts. Use the Export-ADFSDeploymentSQLScript to create the SQL scripts. After the SQL administrator
runs the scripts, try the command again specifying that the database is to be overwritten.
.
At line:1 char:1
+ Invoke-AdfsFarmBehaviorLevelRaise
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [Invoke-AdfsFarmBehaviorLevelRaise], RemoteException
+ FullyQualifiedErrorId : DeploymentTask,Microsoft.IdentityServer.Deployment.Commands.InvokeUpgradeFarmBehaviorCom
mand

Message
——-
Unable to create a newer version of the configuration database. Database upgrade could not be performed on localhost…
In my case, I have a few advanced configurations that may have triggered this error.  First, my ADFS databases are hosted on a remote SQL Server with HA redundancy using SQL AlwaysOn. Also, my ADFS service runs with a gMSA account (Global Managed Service Account).
As of the time of this article, there is my limited documentation on the Invoke-AdfsFarmBehaviorLevelRaise cmdlet. I discovered I could solve this issue by specifying Admin credentials using the -Credential parameter and specifying the -GroupServiceAccountIdentifier parameter to be my gMSA as optional parameters to the Invoke-AdfsFarmBehaviorLevelRaise cmdlet.
In the end, my cmdlet looked like this:
$cred = Get-Credential
Invoke-AdfsFarmBehaviorLevelRaise -Credential $cred -GroupServiceAccountIdentifier <DOMAIN>\mygMSA$
If you are running a similar ADFS configuration and run into this issue, trying adding some the optional parameters to solve the issue.
]]>
/adfs-raise-farm-behavior-level-issue/feed/ 7 551
SCSM: Include Affected/Assigned To User of Parent Work Item in Notifications /scsm-include-affectedassigned-to-user-of-parent-work-item-in-notifications/ /scsm-include-affectedassigned-to-user-of-parent-work-item-in-notifications/#respond Wed, 17 Feb 2016 14:53:31 +0000 /?p=531 If you have ever wanted to include data properties from parent work items in your Service Manager activity notifications, you may have come across this blog: https://blogs.technet.microsoft.com/servicemanager/2012/04/03/using-data-properties-from-the-parent-work-items-in-activity-email-templates/.

This information is great as long as you want to include properties from the Work Item class. However, if you want to include the Affected User or Assigned To User in these e-mails, this gets more complicated as this cannot be generated using the UI.

Below, I have included information required to insert this data into your activity notifications.

Assigned User:
$Context/Path[Relationship=’CustomSystem_WorkItem_Activity_Library!System.WorkItemContainsActivity’ SeedRole=’Target’ TypeConstraint=’CustomSystem_WorkItem_Library!System.WorkItem’]/Path[Relationship=’CustomSystem_WorkItem_Library!System.WorkItemAssignedToUser’ TypeConstraint=’CustomSystem_Library!System.User’]$?$DisplayName$?

Affected User:
$Context/Path[Relationship=’CustomSystem_WorkItem_Activity_Library!System.WorkItemContainsActivity’ SeedRole=’Target’ TypeConstraint=’CustomSystem_WorkItem_Library!System.WorkItem’]/Path[Relationship=’CustomSystem_WorkItem_Library!System.WorkItemAffectedUser’ TypeConstraint=’CustomSystem_Librry!System.User’]$?$DisplayName$?

Note: Be careful copy and pasting this, sometimes the SCSM Subscription wizard has issues with the way text is converted when copy/paste.
Note2: Make sure the MP alias in your notification MP matches mine, if not update the aliases in the above code to match your aliases.

]]>
/scsm-include-affectedassigned-to-user-of-parent-work-item-in-notifications/feed/ 0 531
Software Updates Fail to Detect After Site Recovery /software-updates-fail-to-detect-after-site-recovery/ /software-updates-fail-to-detect-after-site-recovery/#comments Tue, 08 Dec 2015 21:20:57 +0000 /?p=522 I recently ran into a problem where my Software Update point stopped working after performing a Site Recovery of my System Center Configuration Manager Site Server. In my scenario, I was performing a Site Recovery in order to upgrade my OS from Windows Server 2008 R2 to Windows Server 2012 R2 and SQL Server 2008 R2 to SQL 2014 SP1. After the upgrade was completed, all post-recovery steps were done, and all other functions were validated; I found my Software Updates were still not working. When checking Compliance on all updates, they simply reported back “Compliance Unknown”.

I checked through all the SCCM server logs (such as SUPSetup.log, WSUSCtrl,log, wsysmgr.log, etc.) and the SCCM client logs (such as UpdatesDeployment.log, UpdatesHandler.log, UpdatesStore.log, WUAHandler.log, etc.) and did not find any obvious errors. Also, WSUS and SCCM were syncing new updates successfully without error.

After much research and reaching out to Microsoft, I found that the problem is when a Site Recovery happens, the Site Database retains the WSUS/SUP Catalog version, but the SCCM registry keys storing this are not restored (they are reset). To resolve the issue, I had find out what version the catalog was before the recovery and set the registry keys to that value.

The catalog version can be in the ScanAgent.log file, however, debug logging must be turned on first. To enable ensure that HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\CCM\LOGGING\@GLOBAL\LogLevel is set to 0, and create an empty key at HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\CCM\LOGGING\DebugLogging. Once debug logging is enabled, restart SCCM agent and perform a Software Updates scan. Search the ScanAgent.log for Required-ContentVersion=<VersionNumber>. (If multiple catalog versions are found in the log, the one with the highest version is needed).

To resolve the issue, find the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Components\SMS_WSUS_SYNC_MANAGER key. Replace the values in the ContentVersion, SyncToVersion and LastAttemptVersion DWORD entries with the catalog version retrieved above + 1. For example, if Required-ContentVersion=1231, then set the registry values to 1232.

Once these keys have been updated and SCCM has been restarted, Software Updates should begin functioning. For good measure, another WSUS Synchronization can be performed to ensure all is working (the registry values will be incremented by 1).

]]>
/software-updates-fail-to-detect-after-site-recovery/feed/ 2 522
Visual Studio 2015 Breaks New Logins /visual-studio-2015-breaks-new-logins/ /visual-studio-2015-breaks-new-logins/#comments Thu, 19 Nov 2015 19:49:07 +0000 /?p=515 Update: I can confirm that this issue is fixed in Visual Studio with Update 1.

I recently ran into an issue where after pushing out new Visual Studio 2015 installs (with SCCM), new users could not log into those machines. When trying to log in with a new user, the following error occurs: “The User Profile Service failed the logon. User profile cannot be loaded.”

When looking at the Event Logs, I saw access denied errors related to failing to copy some files to the users new profile from C:\Users\Default. (This hidden default profile is what all new user profiles are based from.) 

In doing some research, I saw that there were some similar issues with Visual Studio 2013, but those issues were fixed in later updates.  The root cause for Visual Studio 2015 appears to be similar to what the issue was in Visual Studio 2013; however, the affected files reported in the event logs are different.

In my case, the files in these two directories only had permissions for SYSTEM and Administrators.
C:\Users\Default\AppData\Roaming\Microsoft\VisualStudio\14.0\FeedCache
C:\Users\Default\AppData\Roaming\Microsoft\Blend\14.0\FeedCache

This situation results in Access Denied because the new user account can’t copy these files. (Even if the new user is an Administrator, it still fails if UAC is turned on).  However, the parent directory (FeedCache) has the necessary permissions for this to work. To fix this issue, we simply had to turn inheritance off and then back on for these specific files (this causes the ACLs to get updated from their parent). Once these permissions were updated, then new users were able to login successfully.

I did most of my testing using SCCM to handle the install silently, either via a Task Sequence or Software Deployment. I am not for sure if this issue always occurs when Visual Studio is installed interactively.

To streamline this fix, I wrote a powershell script that can be run after Visual Studio is installed. For example, if installing via a SCCM Task Sequence, you can simply run the script as the next step.  Here is the script that I wrote:

function ResetInheritance ($Path)
{
    # Get Current ACL
    $ACL = Get-Acl $Path
    # Disable Inheritance
    $ACL.SetAccessRuleProtection($true, $true)
    Set-Acl $Path -AclObject $ACL
    # Enable Inheritance
    $ACL.SetAccessRuleProtection($false, $false)
    Set-Acl $Path -AclObject $ACL
}
# Get Files to fix
[array] $Files = Get-ChildItem "C:\Users\Default\AppData\Roaming\Microsoft\VisualStudio\14.0\FeedCache"
[array] $Files += Get-ChildItem "C:\Users\Default\AppData\Roaming\Microsoft\Blend\14.0\FeedCache"

# Fix each file
foreach ($File in $Files)
{
     ResetInheritance -Path "$($File.FullName)"
}
]]>
/visual-studio-2015-breaks-new-logins/feed/ 12 515
Clear SCCM Cache by Deploying a Package /clear-sccm-cache-by-deploying-a-package/ /clear-sccm-cache-by-deploying-a-package/#comments Tue, 17 Nov 2015 19:49:17 +0000 /?p=508 A while back, I wrote a simple PowerShell script that will clear the cache on a SCCM client machine (I will post this script for your reference at the end of this blog).

I mostly used this script during a large Task Sequences (ie. during a build and capture task sequence that installs a lot of software), since the cache would fill completely and then fail the Task Sequences (it appears that SCCM will not override any items in cache during the task sequence). This never presented an issue since I always ran the script directly from the Distribution Point.

However, there is one caveat when executing this script by deploying a SCCM package. It is important that when you deploy the package to use the “Run from Distribution Point” option. If you do not do this, the script will fail. This is because it will be running from the cache that you are trying to clear.

Here is the script I use:

Example Usage to use with SCCM Program: powershell.exe -Command “.\ClearConfigMgrCache.ps1 -DeletePersistent $true”

param(
 [bool] $DeletePersistent
)
$CMObject = New-Object -ComObject "UIResource.UIResourceMgr"
$CMCacheObjects = $CMObject.GetCacheInfo()
$CMCacheElements = $CMCacheObjects.GetCacheElements()
foreach ($CMCacheElement in $CMCacheElements)
{
    if ($DeletePersistent -eq $true)
    {
        $CMCacheObjects.DeleteCacheElementEx($CMCacheElement.CacheElementId, $true)
    }
    else
    {
        $CMCacheObjects.DeleteCacheElement($CMCacheElement.CacheElementId)
    }
}
]]>
/clear-sccm-cache-by-deploying-a-package/feed/ 3 508