Category: System Center

Upgrade Task Sequence (1803) with BitLocker active

With the new 1803 feature update for Windows 10 we got some new and exciting commands for the Windows Setup that we can use in a upgrade task sequence in SCCM to be able to upgrade without suspending BitLocker. For more information about the 1803 feature update, please see this blogpost.

With these new Setup commands you can set a specific value in your task sequence that will try to keep BitLocker active or force it to be active during the upgrade. You can also use the AlwaysSuspend option but as the word explains this will actually suspend BitLocker and that’s not what we want in this post. The different commands are as follows:

  • /BitLocker TryKeepActive
  • /BitLocker ForceKeepActive
  • /BitLocker AlwaysSuspend

In your upgrade task sequence you need to set the variable OSDSetupAdditionalUpgradeOptions to one of the options above depending on how you want the upgrade to handle BitLocker. In this scenario we are using the /BitLocker TryKeepActive value that will attempt to do the upgrade without suspending BitLocker, but if the upgrade fails, Windows Setup will suspend BitLocker and complete the upgrade.

Please note that there are some requirements to get this setup to work.

  • The device being upgraded should be Windows 10 1709 or higher.
  • The Windows device needs to be using Secure Boot and have a TPM.
  • BitLocker needs to be using a TPM protector only.
  • The user profile folder can’t be on a separate volume that is also BitLocker protected.

 

If setup correctly you will find that the command line for the Windows Setup upgrade will add the /BitLocker TryKeepActive to it, as shown below. This can be viewed in the smsts.log.

 

If you have any questions, feel free to email me at tobias.sandberg@xenit.se.



Spring Creators update (1803) for Windows 10

Microsoft released the next feature update on April 30th 2018 that we all have been waiting for. The Spring Creators update (Version 1803) for Windows 10.

It comes with a bunch of new features and I will list some of them that you can benefit from in a deployment perspective.

 

Windows Autopilot

Now enables locking the device during provisioning during the Windows Out Of Box Experience (OOBE) until policies and settings for the device get provisioned.

This means that by the time the user gets to the desktop, the device is secured and configured correctly and can be used right away.

Windows 10 in S mode

The new Windows 10 mode suitable for affordable, cloud-ready devices that offers simple, secure and efficient use for tailored solutions like kiosk, digital sign and task work.

In S mode you will get the following features:

Windows Setup

The ability to control BitLocker under setup with the following commands:

OS uninstall period

Control the OS uninstall period with Intune or DISM.

Windows 10 Subscription Activation

Now supports Inherited Activation that allows Windows 10 virtual machines to inherit activation state from their Windows 10 host.

Feature update improvements

Reduced the time it takes to install the feature update with up to 63% from the Creators Update.

 

Read more about the newest version here.

Very important to notice is the features that Microsoft has removed or not developing anymore. Please see this article for all information about that.

 

Our recommendation is to download this update right now and deploy it to your designated test group. This is an important step to find out if any of your business applications have compatibility issues with the new feature update so you take actions as fast as possible. When you are done with the testing and the feature update (1803) goes Business Ready (usually in a couple of months), you are ready to roll out the update to the rest of the company so everyone can take benefit of the new features.

 

If you have any questions, feel free to email me at tobias.sandberg@xenit.se.

 



Use PowerShell & Windows Update to force drivers to be downloaded from the Internet in a Task Sequence

Working with client driver packages for me is related to a never-ending story. Drivers are frequently being updated and results in manually handling updates of Driver Packages in Configuration Manager. But since some computer manufacturers are releasing updates through Windows Update, so we thought; What if you can use a Task Sequence to force Windows Update to look for updates and drivers over the Internet instead of using manually handled Driver Packages? So I decided to try with a Surface Book.

With help from the PowerShell Module PSWindowsUpdate, created by Michal Gajda (downloaded from TechNet), and with a post from Waingrositblog, I had all the necessary bits forcing a Surface Book to download drivers from Windows Update, over the Internet, while running a Task Sequence. I started by modifying the steps, created by Waingrositblog, in the Task Sequence steps a bit. I found having one step running a PowerShell script instead of three steps, two of which was running cmd lines, more suitable.

This image illustrates the Task Sequence step.

I added the update step just after applying Windows- and Network Settings, where we usually apply driver packages.

The RPS (Run PowerShell) – Microsoft Update step is running the following script:

To verify the success of the script I went through the WindowsUpdateLog.Log and found that during the Task Sequence, a lot of drivers were installed. Here I would like to use PCI drivers as an example. As shown in the image below, the WindowsUpdateLog successfully downloaded and applied the drivers.

This is the WindowsUpdateLog.Log generated after successfully running the Update Drivers sequence.

I also tried the running the Task Sequence without the Windows Update / Driver script and found out the device had conflicts with the PCI drivers. These drivers is just used as an example in this process, there are several conflicts and other drivers missing as shown in the image below.

This image illustrates conflicts with, among others, the PCI drivers after not running the Update Drivers sequence.

This image illustrates when the drivers are applied.

As shown in these images, the Install Driver step running in the Task Sequence finds the correct and necessary drivers. After a Task Sequence successfully has gone through no exclamation marks are found in the Device Manager.

Some computer manufacturers are using Windows Update as a secondary source for updates, and because of this some drivers can be out of date. This is a reason why the Surface is a great example of using Windows Update for drivers since Microsoft release their updates, up to date.

If you have any questions, opinions or improvements, feel free to email me at Johan.Nilsson@Xenit.se



Whats new in Configuration Manager Technical Preview 1708

Microsoft recently released Technical Preview 1708 and with it came some new cool features.

SOFTWARE CENTER CUSTOMIZATION

Add a custom logo, change color in software center and hide tabs. Its all done through the Client Settings for Software Center.

In my example i added a logotype changed the color scheme and disabled the operating system, device compliance and options tab.

The outcome using the Client Settings above.

BUILT IN SUPPORT FOR REBOOTING CLIENTS

This is made through the Client Notification tab
Note This option is only visible when selecting a Collection (Show members) and selecting a single computer.

What the user notification looks like

SCRIPT PARAMETERS

The ability to create Powershell scripts in the console has been around since 1706, in 1707 Microsoft introduced the ability for Configuration Manager to read parameters from the script.
Now in 1708 they expanded the script parameters even further and are now able to detect which parameters are mandatory as well as optional.

MANAGEMENT INSIGHTS

Gives you the ability to see:

  • Empty collections
  • Applications without deployments

Head over to Administration > Management Insights > All Insights to check it out.

 

For more information and documentation: https://docs.microsoft.com/en-us/sccm/core/get-started/capabilities-in-technical-preview-1708

 



SCCM – Shrink the SQL Server Reporting Services log and change the maxsize

The default maxsize value of the ReportServer logfile (ReportServer_log.ldf) is 2 TB. If you haven’t changed that value and your disk size is lower then 2 TB (which is very common) you will eventually fill up that entire disk space. When that happens you need to shrink the logfile before you are able to reduce the maxsize value so it fits your disk size better. In a couple of steps you can easily do this as I will describe below.

1. Shrink the log file.
Go into Microsoft SQL Server Management Studio, expand Databases and locate the ReportServer. Rightclick the database, go to Tasks, Shrink and choose Files as shown in the pictures below.

Task > Shrink > Files

Change File type to Log and select the Released unused space under Shrink action before pressing the OK button. It will now shrink down the log file to a couple of megabytes (instead of gigabytes) and you can go ahead to step two. If it doesn’t work please read below first.

Change File type: Log

If you experience trouble with shrinking the file (like it will only shrink a couple of megabytes or it won’t shrink at all) you need to change the recovery model from Full to Simple before doing the shrink step. To do that you need to go to the Properties of the ReportServer database and choose Options. Here you can change Recovery model to Simple.

ReportServer > Properties > Options

2. Change the maximum file size from the default 2 TB down to a size that fits your environment.
Rightclick the ReportServer database and choose Properties. Select Files in the list and go to the Autogrowth/Maxsize column for the ReportServer and press the button marked in red on the picture below.

ReportServer > Properties > Files

Change the maximum file size limit in megabytes so it suits your environment. Finish it by pressing the OK button.

Change maxsize



SCCM – Application installation summary report

This post will describe how to create an application installation summary report in SCCM. This is a great tool to have when you’re for example doing a health check of your applications and different versions of them. The report is built in Microsoft SQL Server Report Builder and you can see the final result on the pictures down below (press on the pictures to maximize).

I will now describe the different pieces of the report so you can make it fit in your environment:

Add the following datasets to the report, just make sure it is applicable to your environment:

ApplicationCount

ExpandComputerName

ExpandApplicationName

Next step is to create the layout as shown in the picture below. When the layout is done put in the data from the datasets and the two expressions you can see under the picture.

View of the report in Microsoft SQL Server Report Builder.

In the first expression we get the application name from the list search or the wildcard search:

In the second expression we join the computers within each software version result:

Last step is to save the report and try it out.

The report gives you a choice of choosing an application from a drop-down list (where all the applications in your environment will show up) or through a wildcard search. It will then show the selected application (and/or the specific version of your choice) in a list with parameters such as how many computers the application is installed on and the names of the computers.

List of all the applications in your environment.

Wildcard search that overrides the application list search.

A list with the computers that have the application installed.

The view of the report run in Internet Explorer.



OS deployment using same MAC address for multiple clients

OS deployment using the same staging dock for multiple clients is a bit of an issue, and there are many different solutions to the problem but all have their downsides.

I did a quick search and found two probable candidates to tackle.

  1. UUID staging
    The idea is to exclude staging docks using a registry value (new in 1610) and stage using only UUID. This way the MAC address is totally irrelevant and OSD is handled using only UUID. The downside is that many Prestage tools use MAC and the UUID Guid is longer and therefore more prone to mistakes.
  2. Ethernet MAC release/Wifi renew
    This method prompts the user at the end of the task sequence to disconnect the ethernet adapter and then resumes using Wifi. The downsides here is that the task sequence no longer becomes unattended and therefore can take longer time. This also requires the use of extra filtering in task sequences and therefore extra maintenance.

With that said I came to the following solution.
On the Site create a SQL job that runs every 30/60 minutes and removes the MAC association and clears the PXE flag.

This allows users to stage their clients using the same Ethernet adapter (USB or docking station) without changing the current pxe routine/application or task sequence.
As with all staging dock solution some consideration must be taken of when the job is scheduled to run so that MAC address association is not wiped before PXE is initated.
If staging is done once a day/week the schedule can be configured to a daily job and thus the afforementioned consideration becomes a non-issue.

UUID staging
https://blogs.technet.microsoft.com/system_center_configuration_manager_operating_system_deployment_support_blog/2015/08/27/reusing-the-same-nic-for-multiple-pxe-initiated-deployments-in-system-center-configuration-manger-osd/

Ethernet MAC Release/Wifi renew
https://gallery.technet.microsoft.com/scriptcenter/Enable-multiple-SCCM-OS-861e42bb



Convert SCCM schedule to readable format

Reading SCCM Maintenance Windows is not an easy thing to do from WMI as they are stored as 16 char hex values

To get the schedule hex values simply run the below line, but the result might not be easy to understand

A server might return the following values.

Now, how do we read this? The easiest thing is to run Convert-CMSchedule but that unfortunately only works if the configuration manager console is installed.
Another way to do is to invoke a wmi method from a site server using the SMS_ScheduleMethods class.

None of these are portable, so I created my own function to decode these. The below function returns the same data as Convert-CMSchedule but is free from any module as it converts the hex to a readable format.

The function also accepts valuefrompipeline

 

The script is reverse engineered from https://msdn.microsoft.com/en-us/library/cc143505.aspx



SCCM source cleanup inventory

As applications are retired in SCCM the source tend to build up due to human error or retention policy. Either way admins should perform cleanup of the source directory from time to time.
The below script lists all files and folders in the source directory that does not have any active connection in SCCM.

To run the script first open Configuration Manager Console and press ”Connect via Windows Powershell”

 



Ninite <3 SCCM

Ninite Pro

Har man inte använt sig av Ninite hemma har man definitivt gått miste om en fantastisk produkt. I korta drag är det till för alla som ej vill besvära sig med att lägga tid på konstant paketering och uppdatering av de vanligaste applikationer. I skrivande stund supporterar Ninite Pro 112 applikationer. Allt från ramverk som .NET, Java och Flash till mediaverktyg som VLC och Spotify till avancerade utvecklingsverktyg som Eclipse.

Ninite Pro används ofta som ett stand-alone verktyg och kan installera applikationer mot klienter i en domän via det interna administrations interface Ninite Pro erbjuder. Dock kan det lätt bli mycket då varje applikation i infrastrukturen har ett eget verktyg och det är av intresse för IT avdelningar att konsolidera alla verktyg in i ett.

Ninite Pro fungerar som en dröm tillsammans med SCCM och underlättar hanteringen av applikationer samt säkerställer att de alltid håller sig uppdaterade.

SCCM integration

Något som bör tänkas igenom innan implementationen av Ninite Pro är att det har ett eget system för cachning av data vilket innebär att standard cache (och BranchCache) för SCCM inte kan användas. Detta är inget problem och en lösning tas upp i bloggposten.

Först skapas ett SCCM paket med källfiler. Källan är endast NinitePro.exe som används för all installation och konfigurering.

1
Efter detta kan ett program skapas med /updateonly samt /cachepath parametrar sättas upp. Själv föredrar jag att använda en DFS till en NinitePro cache mapp som jag delegerar rättigheter åt datorkonton att modifiera innehåll.
Ninite Pro använder sig av protokollen http/https för nedladdning av data så endast internetåtkomst krävs för installation.
2

Likvärt skapas installationspaket enkelt via /select parametrar. Full lista med applikationer finns i slutet av bloggposten.

Ninite Pro kan också användas för avinstallation av listade applikationer.
3

När alla applikationer är valda är det så enkelt som att deploya ett program till en kollektion precis som vanligt.
4

Efter detta skapas en deployment av ”NinitePro Update” programmet med ett schema. Detta avgör hur ofta applikationerna skall uppdateras. Detta kan konfigureras till ett servicefönster eller varje dag.
5

Vill organisationen istället ”certifiera” programversioner kan initial cache data laddas ner, installeras och verifieras och därefter kan Ninite använda /freeze parametern för att skapa ett paket (.exe fil) med just de versioner som används.

https://ninite.com/help/how-ninite-works/
https://ninite.com/applist/pro.html
https://ninite.com/help/features/offline.html