Powershell

Nice to Know – Defender Sandbox

So another step in the right direction for Windows Defender, it can now run in sandboxed mode. For now you have to turn it on but in the future that will be default.

If you want to read more about the release of this check out the cloudblog from MS here https://cloudblogs.microsoft.com/microsoftsecure/2018/10/26/windows-defender-antivirus-can-now-run-in-a-sandbox/?fbclid=IwAR1BX92wvaqmse7bgucQtPbi_Si6XY1cMfIec9JW1XttX-4wqttIU39mokM

So lets assume you also run ConfigMgr, now this is where its gets intreseting. We can then use a CI to track if it has been turned on!

This is done using a very simple detection script.

image

Here is the small code snippet used to track compliance.

if ($env:MP_FORCE_USE_SANDBOX -eq 1) {
  return $true
}
else {
  return $false
}

Now two things remain, set the data type to boolean and as compliance set to “True”.

All set to measure this. Of course a simple script or package can now be used to force the setting of this, just remeber that its only supported on Windows 10 1703 and later and will require a reboot before taking effect.

Happy deploymnet!

/Peter

Improving the Windows 10 Upgrade Sequence

When you upgrade to Windows 10 or between diffrent Windows 10 versions there are genearlly several things you wish to do. This can include removing “bad” applications or install drivers. Among some common things that needs to be taken care of is diffrent pre-requisites and language packs. This posts covers some things you can improve in your Windows 10 upgrade sequence.

The small things first. As more and more users are working from a laptop a common problem is that someone intiates the sequence when the users has 10% battery left. Now the predicatable outcome is broken upgrade and rollback. To prevent this we can enable a small check to verify if the machine is running on battery power and if so exit the sequence quickly all while we leave a log trace for admins to track.

First we require a small powershell script, download that from here https://github.com/LofgrenP/Scripts/blob/master/Get-xTSRunningOnBattery/Get-xTSRunningOnBattery.ps1

Create a package with source files but no program. Then add a Run PowerShell Step in the begning of your sequence. Use the new package that has been created and set the script name to Get-xTSRunningOnBattery.ps1. Set the execution policy to ByPass.
image

That will take care of machines running on battery. Next common issue is that machines not connected to the wired network won’t reconnect to the network after a restart. To assist with this we can make sure that the upgrade does not run if its not a wired connection.

Download the script needed from here https://github.com/LofgrenP/Scripts/blob/master/Get-xTSEthernetConnection/Get-xTSEthernetConnection.ps1

Create a package with source files and no program then add another Run PowerShell Step in the beginning of your sequence. Use the new package that has been created and set the script name to Get-xTSEthernetConnection.ps1. Set the execution policy to ByPass.
image

With that taken care of lets move on to sorting the language packs. To sort this there are two things we need to sort out. First up is making sure to reinstall all language packs that are already installed. Now Nickolaj Andersen over at SCConfigMgr has an awesome post on how to do that, read that here http://www.scconfigmgr.com/2017/11/06/automatically-retain-installed-language-packs-during-windows-10-servicing/

The final piece to the pussel is making sure that the Language Pack scheduled task does not run. This can be achived in many ways but I prefer to just disable the task after the upgrade is done. For that reasone you can download a small script here https://github.com/LofgrenP/Scripts/blob/master/Disable-xTSLanguagePackTask/Disable-xTSLanguagePackTask.ps1

Now we create another package with source files but without any program and add a final Run PowerShell Step to our upgrade sequence. This time at the very end of the sequence. Make sure to use your new package, set the script name to Disable-xTSLanguagePackTask.ps1 and set the execution policy to ByPass.
image

Now you should be all set to upgrace your machines.

Happy deployments!

/Peter

Refresh scenario and LAPS

When doing reinstall of machines a common issue is that the LAPS password does not get updated due to the fact that the machine thinks the password is current. So to prevent the nice folks from Microsoft wrote a small script to reset the timer and force and update. The original blog post and script can be found here https://blogs.msdn.microsoft.com/laps/2015/05/06/laps-and-machine-reinstalls/

Now my issue with this is there is no log file created and no way for helpdesk to verify it actually happend (besides logging on which I don’t like).

So to solve this I have made an updated version of the script that centralizes logging basone if the script is run as part of MDT, Configuration Manager or Standalone.

image

Script can found on github here https://github.com/LofgrenP/Scripts/tree/master/Clear-xTSPasswordTimeStamp

Updating the MBAM Agent

When upgrading MBAM there are a couple things to note. Number one, if you haven’t already you should make sure you have PowerShell scripts to setup everything on the server side. This will be a nice to have since every servicerelease requires a uninstall/reinstall. And with lots of serviceaccounts, groups and what not, not automating the install will cause you headaches everytime.

The next issue is that the agents needs to be ugpraded everywhere. Now there is no panic to upgrade the agents on the machines as the old version will keep reporting to a newer server release. However to benefit from all the bugs and security fixes the update should absolutley be deployed.

Now the issue, when you run the MSP on an already patches systems (let’s assume you already have a service release installed) nothing happends. Well this is due to the fact that the MSP only upgrades from version 1.0.0.0 as can be viewed in the MSP itself. Below is from the x64 patch of the september release.

image

Now to fix this the easiest way is actually to create a wrapper around the MBAM agent installer and use that to install the agent. That way if there is already and agent installed we can uninstall it and reinstall the patched version. And if there is no version installed we can go ahead and install the version.

All of this can be done using PowerShell and checking the registry for known keys.

image

To save you the time on creating your own script to solve this you can use mine. It can be found on github overe here https://github.com/LofgrenP/Scripts/tree/master/Install-MBAMClient

Now the script requires a simple folder structure looking like this

image

Now in the source folder you place the MbamClientSetup.exe and the patch file from the latest servicingrelease. The script is prepped for the current September 2017 release.

Next up is you run the script as a administrator on a box, or run the script as part of a package in Configuration Manager, an application in MDT or basically however you want.

The logfiles will switch location based on if its run as part of Configuration Manager, MDT or standalone. The end result will always be the same!

Happy upgrading!

/Peter

Redistributing failed content

When working with ConfigMgr you always end up distributing content to several DPs. This normaly goes off without a hitch but from time to time this fails. If you then have several DPs spread across a large geographical area, WAN links may be questionable. So when a package then fails most are not happy to redistribute the content to all DPs again.

image

So to help sort that out the following script can be used. The script will find all failed packages on a specified DP and then redistributed them to that single DP only. All that is needed is to run in on the Primary site server / server with SMS provider and specifiy your SiteCode and DP FQDN.

The script is available on Github over here: Update-ContentForSingleDP

Happy deploying!

/Peter

PowerShell remoting – source vs destination

Powershell remoting, the ability to remotley manage and influence devices is a key part of PowerShell. By default PowerShell remoting is enabled on servers and one of the lazy “security” features you can use is to only allow connections from specified networks.

In a domain network this is very easy to do, all you need is a small group policy that sets the networks. There is one thing you need to note, that is not really documented.

The Group Policy

The group policy is a regular computer policy setting found under “Computer\Policies\Administrative Templates\Windows Components\Windows Remote Management (WinRM)\WinRM Service” and the actual poliy item is named “Allow remote server management through WinRM”

When you enable this policy you can enter networks the server will consider trusted.  So lets say you have your server on the network 192.168.1.0, that would mean you set the filder to 192.168.1.1-.192.168.1.254.

The issue

What you need to consider is the following. Say you have servers on two seperate networks and one is considered management network, lets say it uses 172.16.1.0/24. This means you now specify the management network as approved. But the servers you are accessing is on your primary server network 192.168.1.0/24. You have to specifiy both source and destination networks for this to work as this also controls the actual listners and if you only specify the 172.16.1.0/24 network the listners on the servers on network 192.168.1.0/24 will not be enabled.

The solution

For the scenario above make sure to specify both networks in your GPO. So the filter will be set to 192.168.1.1-192.168.1.254,172.16.1.1-172.16.1.254

winrm

/Peter

Techdays 2017 Pre-Conf Slides

Me and Jörgen Nilsson (@ccmexec) did a pre-conf together at Techdays in sweden. And after much slacking here are now the slide deck from that pre-conf.

Here is the link to download the slidedeck!
https://1drv.ms/b/s!ArAh2CEqOjRkk-8ZDAVJ1vRqi8Glxg

Techday2017

/Peter

Windows 10 1709 Reference Image

Update – 2018-03-06 – Read at the bottom

When creating a Windows 10 reference image a common issue is that the store updates will autoupdate while you are busy installing software updates and applications. This then causes sysprep to fail in giant ball of fire.

To solve this there are basically two options and for some option one doesn’t seem to work which is why I always opt for option two.

Option 1, follow the guidance for disabling auto store updates. This consists of adding a DWORD registry item to HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsStore named AutoDownload with a value of 2. More info on how to do this check out the blog over at deploymentresearch.com

Option 2, is to use a WSUS and then disable internet access for the duration of the build. This can easily be achieved using PowerShell and a sprinkle of magic.

Here is how! Lets start with creating a small PowerShell Script.

param (
[Parameter(Mandatory=$False,Position=0)]
[Switch]$Disable
)

If (!$Disable) {
Write-Output “Adding internet block”
New-NetFirewallRule -DisplayName “Block Outgoing 80, 443” -Enabled True -Direction Outbound -Profile Any -Action Block -Protocol TCP -RemotePort 80,443
}

if ($Disable) {
Write-Output “Removing internet block”
Get-NetFirewallRule -DisplayName “Block Outgoing 80, 443” | Remove-NetFirewallRule

}

Save that into as Invoke-InternetAccess.ps1 and place the file into the MDT deployment share script folder.

Now time to set the sequence.
Add two “Run PowerShell script” steps as shown below.

Ref1709

For the first one just set the script name to Invoke-InternetAccess.ps1
For the second one set the script name to Invoke-InternetAccess.ps1 and parameters to –Disable

All done! Now you can run your sequence and not worry about any store updates during your build.

Update – 2018-03-06
There has been some discussion around this and there is an alternative to the way below which will work if you use MDT. The solution is a simple as it is elegant and requires very little configuration.

All you would need is to set HideShell=YES in your customsettings.ini. This will not load a full explorer and hence store will not start and there will be no store updates downloaded.

 

Happy deploying

/Peter

ADFS Single Sign on with Edge

I usually don’t blog about ADFS but since I recently had to solve this issue for a customer I thought someone else might find it usefull as well.

When you use Edge or Chrome as your primary browser and using a machine that should have SSO with Office 365 and Sharepoint you still get a login page. This happens because by default ADFS have a set of trusted browser strings and others will be prestend with a form authentication.

To fix this on your ADFS server you need to use a couple of simple powershell commands.

Let’s start with just getting what browser strings are trusted currently.

Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents

DefaultSettings

As you can see there browser agent for Edge and Chrome are missing. To fix this we run the following powershell command.

Set-AdfsProperties –WIASupportedUserAgents @("MSAuthHost/1.0/In-Domain","MSIE 6.0","MSIE 7.0","MSIE 8.0","MSIE 9.0","MSIE 10.0","Trident/7.0", "MSIPC","Windows Rights Management Client","Mozilla/5.0","Edge/12")

Then restart the ADFS service

Restart-Service ADFSSrv

That is, you can verify the settings by getting the ADFS properties again

FixedSettings

All done and Single Sign On will should now work using Edge or Chrome as well!

 

/Peter

ConfigMgr 1703 Technical Preview

ConfigMgr 1703 TP has just been released and I am really exited by all the new features! Three of the ones you should check out are the Collapsible task sequence groups, the ability to control Windows Analytics and the direct links to applications in software center

Collapsible Task Sequence Groups

MDT has had this for a long while but now ConfigMgr gets it as well. This will help out while editing a task sequence. And it looks a bit like this

Collapse

Windows Analytics

There is now a new settings group in the client settings that’s called Windows Analytics and there you can enter your Commercial ID (found in the settings of OMS) and select the type of telemetry data sent to Windows Analytics.

It looks a bit like this

CommericialID

When you get data back you can connect Windows Analytics with ConfigMgr and then get collections based on the data in Windows Analytics. For instance a collection with all machines that are ready for the next version of Windows without known upgrade issues.

Shiny!

Create direct links to applications in Software Center

So one request that has been around for a while is the ability for admins to give end users a direct link to the install section of an app in software center. This has previously been done with a workaround and calling the WMI methods involved. Starting with 1703 you can now easily deploy your own link as URL links.

Its pretty straight forward, create a URL link specify the link to be Softwarecenter:SoftwareID=<ApplicationID>

To find the ID either use powershell and the Get-CMApplication command or use the gui end show the column named “CI Unique ID”

You will then end up with a URL looking something like this

Softwarecenter:SoftwareID=ScopeId_96EF26AC-1571-4633-9CE4-1A51DCC38B84/Application_3e312927-bcd9-4fea-8066-0e407d051037

Note that this new feature requires the new agent version available with 1703 and does not work with previous agent versions.

Below is a short script that can help you easily create these shortcuts. Just run it on your CM Server or a machine with the console installed. Select the applications you want and it will create the shortcuts on your desktop ready for distribution to other machines.

<#
Created:     2017-03-31
Version:     1.0
Author :     Peter Lofgren
Twitter:     @LofgrenPeter
Blog   :     https://syscenramblings.wordpress.com

Disclaimer:
This script is provided "AS IS" with no warranties, confers no rights and
is not supported by the author

Updates
1.0 - Initial release
#>

# Import the ConfigurationManager.psd1 module
Import-Module "$($ENV:SMS_ADMIN_UI_PATH)\..\ConfigurationManager.psd1"
# Set the current location to be the site code.
Set-Location "$((Get-PSDrive -PSProvider CMSite).Name):"

#Get Application Name
$AppName = Get-CMApplication | Select LocalizedDisplayName | Out-GridView -PassThru
foreach ($App in $AppName) {
  $Application = Get-CMApplication -Name $App.LocalizedDisplayName

  #Get Application ID
  $ID = ($Application.CI_UniqueID -split "/")[0] + "/" + ($Application.CI_UniqueID -split "/")[1]

  #Create URL Link on desktop
  $Shell = New-Object -ComObject ("WScript.Shell")
  $Favorite = $Shell.CreateShortcut($env:USERPROFILE + "\Desktop\$($App.LocalizedDisplayName).lnk")
  $Favorite.TargetPath = "SoftwareCenter:SoftwareID=$ID";
  $Favorite.IconLocation = "C:\Windows\ccm\SCClient.exe, 0";
  $Favorite.Save()
}

$Favorite.Save()

If you want to read more about the other new features check out the post by the team here https://blogs.technet.microsoft.com/enterprisemobility/2017/03/30/update-1703-for-configuration-manager-technical-preview-branch-available-now/

/Peter