CCMEXEC.COM – System Center blog

CCMEXEC.COM – by Jörgen Nilsson

Browsing Posts in System Center Configuration Manager

I wrote a handy little VBscript a couple of years ago that can be triggered by a Status Filter Rule to automatically distribute packages as soon as they are created to a Distribution Point. When upgrading to MDT 20213 Update 1 I missed this so I re-wrote it in Powershell. The script is triggered by a Status Filter Rule and then distributes the content to the DP group that is configured in the Powershell script. I am lazy I know ;-)

Below is the script, change the $DPgroup variable to the name of your DP group.
It can also be configured with the $CopyToShare variable to configure the package to be available on the package share if that is used. I used it in some environments to speed up OS deployment and use the “Access content directly” option for the Task Sequence when bandwidth is no issue. Save the script in a folder on the Primary Site server.

Param(

[string]$PackageID

)

$DPgroup = "All DP"

$CopyToShare = $False

import-module $env:SMS_ADMIN_UI_PATH.Replace("bin\i386","bin\ConfigurationManager.psd1") -force

[String]$SiteCode = $(Get-WMIObject -ComputerName “$ENV:COMPUTERNAME” -Namespace “root\SMS” -Class “SMS_ProviderLocation”).SiteCode

new-psdrive -Name $SiteCode -PSProvider “AdminUI.PS.Provider\CMSite” -Root “$ENV:COMPUTERNAME” -Description “SCCM Primary Site”

Set-Location “$SiteCode`:”

# Configure the package to be availble on DP Share

if($CopyToShare) {

Set-CMPackage -Id $PackageID -CopyToPackageShareOnDistributionPoints $True -ErrorAction SilentlyContinue

}

# Add to distributionpoint group

Start-CMContentDistribution –PackageID $PackageID –DistributionPointGroupName $DPgroup

Param(

[string]$PackageID
)
import-module $env:SMS_ADMIN_UI_PATH.Replace("bin\i386","bin\ConfigurationManager.psd1") -force
[String]$SiteCode = $(Get-WMIObject -ComputerName “$ENV:COMPUTERNAME” -Namespace “root\SMS” -Class “SMS_ProviderLocation”).SiteCode
[String]$DPgroup = "All DP"
new-psdrive -Name $SiteCode -PSProvider “AdminUI.PS.Provider\CMSite” -Root “$ENV:COMPUTERNAME” -Description “SCCM Primary Site”
Set-Location “$SiteCode`:”
# add to distributionpoint group
Start-CMContentDistribution –PackageID $PackageID –DistributionPointGroupName $DPgroup



The Status filter rule we need to create will look like this, trigger on Message ID: 30000

StatusFilterRule

For the Actions to run, the following command line needs to be used like shown below.

C:\Windows\System32\WindowsPowerShell\v1.0\Powershell.exe -NoProfile -ExecutionPolicy ByPass -File E:\Scripts\Addtodp.ps1 “%msgis02″

The variable %msgis02% will be used to pass the package ID to the script from the Status Message.

StatusFilterRule2Then you are all done, no more forgetting to add a package to a DP anymore.

I wrote a blog post earlier about how to uninstall built-in apps from Windows 10 CBB using Powershell, http://ccmexec.com/2015/08/removing-built-in-apps-from-windows-10-using-powershell/ however some apps cannot be uninstalled like Microsoft Edge, Contact Support and Windows Feedback.

They can be blocked using Applocker instead that is the best workaround I have found. Blocking them using an Applocker policy is working really well, if the user never logged on to the computer before the Applocker policy is applied the application, in this case Contact support is not installed for the user at all and therefor not present either on start or by using search which is really great!

If the user have logged on to the computer before the Applocker policy is applied the applications is present but the user can no longer start it, and will get the below message displayed.
BlockContactSupport10So this method could be used instead of uninstalling the apps as the end result for the end-user is basically the same if they haven’t logged on to the computer before the policy is applied.

The challenge with that right now is there is no RSAT for Windows 10 available yet so creating the policy is a a bit of a challenge. So I ended up creating the Applocker policy locally on a Windows 10 computer and then export it and then import it on a Windows 2012 R2 server with the Group Policy Management MMC installed.

Here are the steps for creating a Group Policy to block Contact Support, the same steps would be used to block Microsoft Edge and Windows Feedback if that is a requirement for you as well.

1. Create a new Group Policy for this test.

2. Under Computer Configuration\Policies\Windows Settings\Security Settings\System Services change the startup to Automatic for the Application Identity Service. This service must be started for the Applocker policies to be enforced on the client computers.
BlockContactSupport

3. On a Windows 10 computer running the Enterprise version start Group Policy Editor by typing Edit Group Policy in the search Taskbar.

4. Under Computer Configuration\Windows Settings\Security Settings\Application Control Policies\Applocker right-click and select Properties and enable Packaged app Rules and select Enforce rules.
BlockContactSupport1

5. Then we need to create two Packaged app Rules one default rule to allow all apps to run and one rule to block the Contact Support app in this scenario.

6. Right-Click Packaged app Rules and select Create default Rules, this will create a rule that allows all signed apps to be executed. Note that this setting only applies to Apps and not Win32 applications.
BlockContactSupport3 7. Then we create a new Package app Rule by right-clicking Packaged app Rules and select Create New Rule

BlockContactSupport28. On the next screen we select to Deny this app to run for Everyone.
BlockContactSupport4

9.  Then select Use and installed packaged app as a reference and click select.
BlockContactSupport5 10. In the next dialog select the apps you want to block, in my case the Contact Support app, then select OK, and Create
BlockContactSupport6

11. Now we have a policy created locally on the Windows 10 computer with the correct policy shown below.

BlockContactSupport11

12 In the Applocker node in Group policy editor Right-Click and select Export policy. Save the file on a share so you can access it from the computer where you are running the Group Policy Management MMC.
BlockContactSupport7 13. On the computer running the Group Policy Management MMC edit the Group Policy we created in AD in step 1 and under Applocker in the group policy editor select Import Policy and import the policy exported from the Windows 10 computer.
BlockContactSupport814. You will be prompted that it will overwrite all existing policies.
BlockContactSupport9Now we have a policy that can be deployed to Windows 10 that will block the Contact Support app!

Time to start testing.

When deploying Windows 10 one of the most common things you want to do is to modify the default wallpaper. Windows 10 uses different backgrounds depending on the resolution you use. If you use any of the following resolutions, 768 x 1024, 768 x 1366, 1024 x 768, 1200 x 1920, 1366 x 768, 1600 x 2560, 2160 x 3840, 2560 x 1600, 3840 x 2160 the file matching the resolution  in the following folder %Windir%\Web\4K\Wallpaper\Windows will be used.
Win10Backgrounds

If the resolution used doesn’t match any of the above resolutions the default background %Windir%\Web\Wallpaper\Windows\img0.jpg will be used instead.

So a script that replaces these files will do the trick, the files however are owned by TrustedInstaller and TrustedInstaller is the only user that has permissions to change it as well.
Win10Backgrounds1

To be able to replace them using a script either in MDT or SCCM we need to take ownership of the files and then change the permissions on them so we can replace them with our own custom background images.

I have created to script that can be used, on old school .cmd file and a Powershell script both works, so you can choose which one you want to use. Place your own custom backgrounds in the 4K folder and the img0.jpg file in the same folder as the script like this.

Win10Backgrounds2

Important to note as well, if you use SCCM to deploy the script the System account will be used, you use MDT you need to change this to Administrators instead for the script to work as the Task Sequence isn’t executed in System context.

Download the script and create a package that can be used by either a “Run Command Line” step or “Run Powershell Script” step in the task sequence.

The .CMD file content:

takeown /f %WinDir%\WEB\wallpaper\Windows\img0.jpg

takeown /f %WinDir%\Web\4K\Wallpaper\Windows\*.*
icacls %WinDir%\WEB\wallpaper\Windows\img0.jpg /Grant System:(F)
icacls %WinDir%\Web\4K\Wallpaper\Windows\*.* /Grant System:(F)
del %WinDir%\WEB\wallpaper\Windows\img0.jpg
del /q %WinDir%\Web\4K\Wallpaper\Windows\*.*
copy %~dp0img0.jpg %WinDir%\WEB\wallpaper\Windows\img0.jpg
copy %~dp04k\*.* %WinDir%\Web\4K\Wallpaper\Windows

takeown /f c:\windows\WEB\wallpaper\Windows\img0.jpg
takeown /f C:\Windows\Web\4K\Wallpaper\Windows\*.*
icacls c:\windows\WEB\wallpaper\Windows\img0.jpg /Grant System:(F)
icacls C:\Windows\Web\4K\Wallpaper\Windows\*.* /Grant System:(F)
del c:\windows\WEB\wallpaper\Windows\img0.jpg
del /q C:\Windows\Web\4K\Wallpaper\Windows\*.*
copy %~dp0img0.jpg c:\windows\WEB\wallpaper\Windows\img0.jpg
copy %~dp04k\*.* C:\Windows\Web\4K\Wallpaper\Windows


And the Powershell Script:

takeown /f c:\windows\WEB\wallpaper\Windows\img0.jpg
takeown /f C:\Windows\Web\4K\Wallpaper\Windows\*.*
icacls c:\windows\WEB\wallpaper\Windows\img0.jpg /Grant 'System:(F)'
icacls C:\Windows\Web\4K\Wallpaper\Windows\*.* /Grant 'System:(F)'
Remove-Item c:\windows\WEB\wallpaper\Windows\img0.jpg
Remove-Item C:\Windows\Web\4K\Wallpaper\Windows\*.*
Copy-Item $PSScriptRoot\img0.jpg c:\windows\WEB\wallpaper\Windows\img0.jpg
Copy-Item $PSScriptRoot\4k\*.* C:\Windows\Web\4K\Wallpaper\Windows

Both scripts can be downloaded here as well in this .zip file.

So why not just change the default background using a GPO for instance? One reason would be that you miss out on the dynamic selection of background that matches your resolution.

Microsoft Edge is the new always up-to-date, ultrafast and modern browser in Windows 10 CBB It is not included in the Long-Term Servicing Build of Windows 10. Microsoft Edge doesn’t share favorites with IE, it has its own favorites store which is located here: %Userprofile%\appdata\local\packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\ac\MicrosoftEdge\User\Default\favorites

In Edge there is a built-in feature to copy favorites from IE, Chrome or Firefox. However if you are using folder redirection for IE favorites so they aren’t located under %userProfile%\Favorites anymore then you will be met with this error message when you try to copy the favorites from IE in the Edge browser.

Edgeimport1

I created a little PowerShell script that will copy the favorites from both a redirected and a non-redirect favorites folder that can be run in the user context to copy the favorites from IE to Edge. It also deletes the registry key necessary for Edge to read the new favorites, it also excludes $recycle.bin file that can exist in the redirected favorites folder.

I have uploaded the script to Technet Galleries, it can be found here: https://gallery.technet.microsoft.com/Powerhsell-script-to-copy-1e300de5

Note that Edge must have been started once so that all the registry keys are inplace. I am hoping that the Edge team will solve this for us in the future but until then launching and stopping the Edge browser when you build your reference image in MDT and then use Copyprofile during deployment solves the need to start Edge once before copying of the favorites are successful.
Thanks to my colleagues Johan and Petrus for assisting in the testing and verification.

I hope this can be useful.

When deploying Windows 10 CBB in an Enterprise some of the built-in apps will need to be removed for various reasons. I have used the excellent script that Ben Hunter wrote to do this in Windows 8/8.1 here http://blogs.technet.com/b/deploymentguys/archive/2012/10/26/removing-built-in-applications-from-windows-8.aspx

It removes the install .Appx packages in the list for the logged in user and the pre-provisioned package as well which means that the app is also uninstalled from the computer.

It doesn’t work anymore in Windows 10. After some investigation the reason is that the Package name is not the same for the installed Appx package as for the pre-provisioned.
Get-Appxpackage returns “microsoft.windowscommunicationsapps_17.6106.42001.0_x64__8wekyb3d8bbwe”

Get-AppxProvisionedPackage returns “microsoft.windowscommunicationsapps_2015.6106.42001.0_neutral_~_8wekyb3d8bbwe”

So I re-wrote the script to work in Windows 10, I also wrote a simple script to list all the App names that are installed on the computer so you easily can copy them to the script. It creates a file called C:\Temp\apps.txt

$Appx = Get-AppxPackage | select name
$appx | Out-File -FilePath C:\temp\Appx.txt

The updated script that will remove the packages you have in the $Applist variable and all the pre-provisioned packages. Here is the powershell script.

$AppsList = "Microsoft.BingFinance","Microsoft.BingNews","Microsoft.BingWeather","Microsoft.XboxApp","Microsoft.SkypeApp","Microsoft.MicrosoftSolitaireCollection","Microsoft.BingSports","Microsoft.ZuneMusic","Microsoft.ZuneVideo","Microsoft.Windows.Photos","Microsoft.People","Microsoft.MicrosoftOfficeHub","Microsoft.WindowsMaps","microsoft.windowscommunicationsapps","Microsoft.Getstarted","Microsoft.3DBuilder"
ForEach ($App in $AppsList)
{
$PackageFullName = (Get-AppxPackage $App).PackageFullName
$ProPackageFullName = (Get-AppxProvisionedPackage -online | where {$_.Displayname -eq $App}).PackageName
write-host $PackageFullName
Write-Host $ProPackageFullName
if ($PackageFullName)
{
Write-Host "Removing Package: $App"
remove-AppxPackage -package $PackageFullName
}
else
{
Write-Host "Unable to find package: $App"
}
if ($ProPackageFullName)
{
Write-Host "Removing Provisioned Package: $ProPackageFullName"
Remove-AppxProvisionedPackage -online -packagename $ProPackageFullName
}
else
{
Write-Host "Unable to find provisioned package: $App"
}
}


Here is a .zip file with both scripts that can be downloaded here: download

I have had the opportunity to implement Intune together with customers where we have implemented the Apple DEP program together with Intune. DEP stands for Device Enrollment Program and is the recommended way of managing company owned iOS devices as it can configure the iOS device to be enrolled during setup of the device even after a reset. It can also configure the iOS device to be in Supervised mode as well which allows for many more management capabilities. All this is done over-the-air so no cable or handling needed by the IT department just register the device in DEP and then send it directly to the end-user, you can configure the first time setup wizard using Intune and controlling which options should be available. You could say that DEP is the same as Apple Configurator over-the-air also note that DEP is not avilable in all countries which also could be a challenge.

In Intune you can configure one or more DEP policies in Intune where you can control the settings shown below.

DEP1dep2

A device registered in Apple DEP program cannot be “un-enrolled” if you reset the device it will force you to register with the Intune again in the first time experience. As your DEP enrollment policy dictates. Supervised mode is really important for at least company owned devices as you get more management capabilities like the following policies:

  • Global network proxy for HTTP
  • Allow iMessage
  • Allow Game Center
  • Allow removal of apps
  • Allow iBooks Store
  • Allow podcasts
  • Allow user-generated content in Siri
  • Allow manual installation of configuration files
  • Allow configuring restrictions
  • Allow pairing to computers for content sync
  • Allow AirDrop
  • Allow account modification
  • Allow cellular data settings modification
  • Allow Find My Friends
  • Allow Erase All Content and Settings
  • Restrict AirPlay connections with whitelist and optional connection passcodes
  • Enable Siri Profanity Filter
  • Single App Mode
  • Accessibility settings

More information about the Apple DEP program can be found here: https://www.apple.com/business/dep/

You can register iOS devices you have already bought as well in DEP, “Mac or iOS devices purchased on or after March 1, 2011 can be enrolled in DEP Mac or iOS devices purchased from participating Apple Authorized resellers or carriers must be added to your DEP instance to be included” from the DEP frequently asked questions section. This is a nice option once you got management commitments to actually take control of you device as in many companies these policies are still non-existent.

I have done this in a couple of implementations where we have imported iOS devices that are already in use by the end user, and here as some pointers that can be good to know.

  • If a device is enrolled in Intune using the Company Portal and then added to DEP and synced to Intune it will be removed from the Intune console and replaced by the object synced from DEP. You will need to reset the device and enroll it using DEP instead.
  • If a device is synced from DEP it cannot be enrolled using the Company Portal as it has an active DEP policy deployed to it.
  • You cannot “unenroll” a device that is enrolled using DEP
  • You can remove a device from DEP if it is stolen for instance but once removed it can never be added back to DEP.

DEP and Intune is best together! DEP is the way I would recommend managing your company owned iOS devices.

I hope that can be helpful

In the middle of vacation times at least in Sweden a new update was released that requires multiple reboots and therefor will fail an OS deployment task sequence in Configuration Manager as we seen a couple of times before. This issue is addressed i System Center 2012 Configuration Manager SP2 and R2 SP1 but if you haven’t upgraded yet then it still will cause an issue.

The update is: KB3073094

And the article that lists all the updates that requires multiple reboots is updated as well: https://support.microsoft.com/en-us/kb/2894518

Thanks for the heads-up Tim: https://twitter.com/t1mnl well spotted!

In September the Windows 10 Tour in Sweden takes place! Presented by Addskills, Cornerstone and Microsoft.

We will be turning Windows 10 inside and out from every angle you can image. Join Me and fellow MVP’s, Sami Laiho and Paula Januszkiewicz when we deep dive into Windows 10 in four cities in Sweden. I am really looking forward to it!

I have the great pleasure of presenting two sessions:

-”Deploying Windows 10 using Configuration Manager”, we will cover SCCM vNext as well during this session.

-”Windows 10 Azure AD and EMS”

Umeå – 21 September

Sotckholm – 22 September

Malmö – 23 September

Göteborg -24 September

I hope to see you all there!

win10tour