Technology Log

We found an issue where our Citrix Admins couldn't install software from software center or application catalog. Found the client was refusing user policy. After some digging we found that user policy is disabled by default in 1906 and no GUI way to flip it until CM 1910. You can confirm this with the following sql command. You will have to open the resulting xml blob to view. SELECT SiteControl FROM vSMS_SC_SiteControlXML WHERE SiteCode = 'SiteCode' To make the change to policy you have to make the update via wbemtest and it will be apply to all setting. This becomes a regular client policy setting in 1910. Wbemtest Connect to your site server namespace Enum Instances = SMS_SCI_ClientComp Select “Software Distribution” Open “Props” View Embedded Last one in list Open Verify “Request User Policy On TS” Open “Value” Change to “1 (0x1)” Save object on all dialogs Verify the change via the same SQL from the beginning. SELECT SiteControl FROM vSMS_SC

If you ever need to see the DP location list coming from SCCM MP to a client. Here is a nifty script that will let you put in the information and see what it returns. Basically synthetic MP calls for DP Content List. [void] [Reflection.Assembly]::LoadWithPartialName("System.Diagnostics") [void] [Reflection.Assembly]::LoadFile("c:\Microsoft.ConfigurationManagement.Messaging.dll") $ManagementPointSiteCode = "COP" $ManagementPoint = "Server.FQDN.local" $PackageID = "PackageID" $PackageVersion = "PackageVersion" $myDomain = "Domain.Whatever" $myForest = "Forest" $myCustomAdSite = "ADSite" # Set up the objects $httpSender = New-Object -TypeName Microsoft.ConfigurationManagement.Messaging.Sender.Http.HttpSender $clr = New-Object -TypeName Microsoft.ConfigurationManagement.Messaging.Messages.ConfigMgrContentLocationRequest $cmReply = New-Object -TypeName Microsoft.ConfigurationManage

This one is pretty self explanatory. If you use BranchCache by default it puts the caches on C: drive and you might find that your C: is the smallest drive (depending on your server configuration). Anyways here is something that will help you move those caches around and set them to a different size. #Check if cache already moved $CacheStatus = Get-BCStatus If(($CacheStatus.HashCache.CacheFileDirectoryPath -like 'E:\')-or($CacheStatus.DataCache.CacheFileDirectoryPath -like 'E:\')) {     Set-BCDataCacheEntryMaxAge -TimeDays 10     Return "Already Moved" } elseif ((Get-Volume -DriveLetter E).FileSystem -ne "NTFS") {     # Set Cache Sizes     get-bchashcache | set-bccache -Percentage 2 -Force -Confirm:$false     get-bcdatacache | set-bccache -Percentage 1 -Force -Confirm:$false     Set-BCDataCacheEntryMaxAge -TimeDays 10     Return "Destination Not NTFS" } else {     #Create New Directories     $rootPath = "E:\data\Br

Greetings folks Here is another bit you might find fun and exciting. You ever have the need to setup/modify apps to allow download from neighbors (that little drop down box, not the check box for default boundary). Then you are in luck. Take a look at the following $OutFileName = "C:\EnterLogNameHere.log" $AllApps = Get-CMApplication $Agent99 = $AllApps | Where-Object {$_.LocalizedDisplayName -like "*IfYouWantToLimitIt*"} foreach($appType1 in $Agent99) { $allTypes1 = Get-CMDeploymentType -ApplicationName $appType1.LocalizedDisplayName forEach($appType in $allTypes1) { If ($appType.Technology -contains "MSI") { #"MSI" $appType.LocalizedDisplayName +";"+ $appType.Technology +";"+ "Updated to Download" | Out-File $OutFileName -Append Set-CMMsiDeploymentType -ApplicationId $appType1.CI_ID -DeploymentTypeName $appType.LocalizedDisplayName -SlowNetworkDeploymentMode Download      } elseif ($appType.

We ran across a head scratcher with some Citrix App Layering VDI machines. What it boiled down to is that the master image didn't have everything cleaned out of the client like we thought. There is apparently a new "feature" in the Citrix system that creates a "Citrix Profile" that SCCM ends up putting a backup file in. The only problem with that is that unless the file is removed from this hidden folder partition. The GUID will be picked up by all the VDIs that are made from that master. Even if you change the GUID on one it will change them on all of them. After Citrix support said it wasn't them MSFT support was able to provide the following useful information to clean up this scenario. For each user VM In the SCCM Console: delete the Computer object for this VM On the VM: net stop CCMexec Del %windir%\smscfg.ini delete SMS certificates open disk manager, Locate the hidden partition "c:\program files\Citrix\pvsvm\Se