Technology Log

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 ...

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...

In general I don't recommend anyone do this unless you have to. Especially in environments where a user has more than one machine. Now I know you're thinking 'why not just target users' well that is a good question. In this case I needed to add an exclude collection to the machine collection to prevent installation on certain machines. But if you ever find yourself in such a predicament. Here you go. select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_SYSTEM_CONSOLE_USER on SMS_G_System_SYSTEM_CONSOLE_USER.ResourceID = SMS_R_System.ResourceId inner join SMS_R_User on SMS_R_USER.UniqueUserName = SMS_G_System_SYSTEM_CONSOLE_USER.SystemConsoleUser Where SMS_R_User.UserGroupName = "Domain\\ADGroup"

Had an instance of needing to reach HKEY_CLASSES_Root with powershell and found it doesn't have an HKCR built in. Ended up finding a post that had a simple solution and wanted to pass it along. For full details see: https://blogs.msdn.microsoft.com/lior/2009/06/18/what-no-hkcr-in-powershell/ Otherwise here is the important bit that I used: New-PSDrive -Name HKCR -PSProvider Registry -Root HKEY_CLASSES_ROOT

So I found that if you happen to be in an environment were you have more than one mailbox and you have permissions to send from that other mailbox. You might think that just using the From attribute in the object would send your email from that other mailbox. Well if you thought that you would find you are mistaken (or at least I was). You have to use the "SentOnBehalfOfName" attribute to be able to make your email send from that other mailbox. Here is a handy little function to give you a hand. function Send-Email ( [string] $ Address , [string] $ CCAddress , [string] $ BCCAddress , [string] $ Subject , [string] $ HTMLBody , [string] $ FromAddress) { $ Outlook = New-Object - ComObject Outlook.Application $ Mail = $ Outlook .CreateItem ( 0 ) If(!( [string] ::IsNullOrWhiteSpace ($ FromAddress ))) { $ Mail .SentOnBehalfOfName = $ FromAddress } If (!( [string] ::IsNullOrWhiteSpace ($ CCAddress ))) { $ Mail .CC = $ CCAddress...