Category: System Center

How to handle pinned start menu apps in Windows 10

As I have been working with customizing Windows 10 for a while now, it has never worked against me this much. However, sometimes Windows do have its ways of working against you. With challenges like these you get the opportunity to spend a lot of time coming up with a solution. So this blog post is about my battle with the start menu of Windows 10 Professional. If you are here for the quick solution, skip to the bottom and the TL;DR section.

The Problem:

I have been able to customize the start menu of Windows 10 with ease since version 1511 with the Export / Import-StartLayout cmdlet. But this time I got a request to remove all the pinned apps on the right side of the start menu. A colleague discussed this and he told me he had done a similar solution inside a Citrix Virtual Desktop, and he spent quite the amount of time with this, I thought this would be much easier than it turned out to be. So the requested start menu should at the end look something like this upcoming picture, with the following demands:

  • No pinned apps on the right box or the start menu
  • In the task bar, have Chrome & Explorer pinned. 

This was the requested layout

To begin with, I created an XML file with just Chrome & Explorer pinned in the task bar, and having set the <DefaultLayoutOverride LayoutCustomizationRestrictionType=”OnlySpecifiedGroups”> . My thought was that this would give me a clean start menu, but this was my first failed attempt. The colleague of mine who preciously had a similar issue in a Citrix environment had during his research time come across this post containing a script called ”Pin-Apps”. This script contained a Unpin function which turned out to be very helpful. So I started adapting my work after this script. But this is where I came across my second setback. First, I was not able to have this script and the Import-StartLayout-script in the same logon script, nor having one script on startup, and one on login, so I had to think of a way configure this in my isolated lab environment.

Luckily, I’ve been working a lot with OS-deployment, so I created a Task Sequence containing the Import-StartLayout-script, which managed to run successfully together with my login-script containing the Pin-Apps script. But here I came across my third setback, which by far had the most impact and was the one I spent the most time struggling with. For some reason I was not able to remove bloatware, such as Candy Crush, Minecraft etc. The script ran successfully, but every time, the outcome looked like this

Some applications would not be removed

I could not understand why these applications would not be removed. I have had to deal with bloat ware before, but then it was just to remove them with Appx-cmdlets. I checked Get-AppxPackage & Get-AppxProvisionedPackage, and ran Remove-AppxPackage and Remove-AppxProvisionedPackage several times, but these apps were not removable and did not show up until I manually selected them, and they started downloading (as shown on the application in the top right corner on the picture). So apparently they were either links or shortcuts to the Windows Store. This is works if you are using Windows 10 Enterprise. 

This is where I started going deep. The apps were all published in the Windows AppStore, so I started looking for any kind of possibilities, with help from Powershell, to by force download all apps in the Windows Store. I spent a lot of time with this, but without any success. So I had to rethink my plan. There was no way to have the bloat ware-applications to be downloaded by force, there was no way to remove them by removing them with Appx-cmdlets, and there was no way to have a clean start menu with a XML-file. This gave me the idea. If you can’t beat them, join them. There was no way to actively remove all the applications from the start menu of a Windows 10 Professional, but replacing them worked.

The solution:

As I have yet to find any other way of removing the superfluous applications, creating a new XML replacing the start menu with some random default applications was the only successful way for me. To list these applications, go to Shell:AppsFolder or shell:::{4234d49b-0245-)4df3-b780-3893943456e1} in file explorer.

Applications can be found here

I just chose to pin some of the applications which were default on my start menu, that I knew was very much removable, exported these to a new XML which turned out to it look like this:

From here I had to modify the Pin-Apps script to make it more suitable for a Swedish operating system, and added a register key so it would not run more than once on each user. If you want to lock down the right side of the start menu, you just set or create the LockedStartLayout registry key, located under both HKEY_Local_Machine & HKEY_Current_User\Software\Policies\Microsoft\Windows\Explorer, to 1

If you are running another OS language than Swedish or English, to find the verb for unpin, simply save an application name to the variable $appname (as an example I will use Windows Powershell) and run the following part: 

This will give you all the verbs which are applied to this application. In this case ”Unpin from Start” is present.

After modifying the necessary bits I added it to a PowerShell logon script GPO with the parameter -UnpinAll, with the .ps1 file located inside the GPO repository, making sure it’s accessible for everyone.

 

TL;DR: 

If you are running Windows 10 Professional, you need to replace applications in the start menu before removing them, as a suggestion running in a Task Sequence of some kind setting the default start menu layout and then have a GPO to run the PowerShell script stated above.

If you are running Windows 10 Enterprise, just use the Logon script GPO and you will be fine. If you still have some unwanted applications, run a script removing built-in apps (for example this Invoke-RemoveBuiltinApps )

If you have any questions or thoughts about this post, feel free to email me at johan.nilsson@xenit.se



SCCM 1806 – News and features

Once more it was time to upgrade our SCCM environment to the newest release that is 1806. As it was not released for everyone yet, I had to run the Fast-Ring script to allow the update to present itself. I found this update very interesting as it comes with some exciting new features, and there are alot. These are the ones that I am most excited about.

  • Ability to PXE boot without WDS
  • CMTrace installed as default on clients
  • Ability to exclude Active Directory containers from discovery
  • High availability on Site Server
  • CMPivot
  • Boundary group for peer downloads
  • Enhanced HTTP site system
  • Improvements to OS deployment
  • Software Updates for third-party

…and much more. You can read about all the new features here on Microsoft docs.

Since there are a lot of news, I have chosen to cover the two that I am most excited about in this new release.

CMPivot

Configuration Manager is a very helpful tool when gathering information, CMPivot now allows you to take it to the next step by real-time querying clients. This allows you to gather a lot of information instantly. This feature uses Azure Analytics Language, .

CMPivot is located under Asset and Compliance > Overview > Device Collection, you can find this new feature in the top ribbon bar.

Location of CMPivot

An example is to find BIOS-information about the Dell computers that are currently online. From this output you easily create a collection (the members of the collection will be added as Direct Members) or export to both CSV and Clipboard.

 

PXE Without WDS

It is exciting to have a new way of deploying over PXE. Since Windows Deployment Services has been available for a long time, it feel suitable to have an updated way of deploying clients. By replacing WDS, the distribution point will create the service ConfigMgr PXE Responder. If you have plans of using Multi-Cast, you are for now stuck with WDS.

This setting can be found under Administration > Overview > Distribution Point, right click on the distribution point you would like to modify with the setting shown below.

After applying this setting, Windows Deployment Services will automatically be disabled. Be advised that if you are monitoring this service, it will be report as stopped. SCCM PXE Without WDS

If you have questions, thoughts or anything you would like discuss? Send an email to Johan.Nilsson@xenit.se and I will be more than glad to talk about these topics.



Specific computer model not joining the domain.

I recently had an issue with a specific computer model not joining the domain. The Task Sequence had not been updated for a while, and we had not done any significant changes to the environment. With other computers working flawlessly, we had issues with a HP EliteDesk 800 G3 DM 35W not joining the domain for some unclear reason. This was the start of an interesting discovery.

The issue began when this EliteDesk 800 G3 wouldn’t join the domain. Usually when a Task Sequence finishes, the computer reboots and you see a login screen, stating the domain and asking for credentials, as shown in this picture.

Usual image after a successful Task Sequence

This time the EliteDesk didn’t show any domain, just asking for local Administrator credentials. My first guess was network drivers, so I started by updating the boot image with fresh network drivers for EliteDesk 800 G3. Even with up-to-date drivers the computer wouldn’t join the domain. I started going through the SMSTSLog, BDD.log, checked if something had failed during the Task Sequence. No errors were found. But still, the computer would not join the domain.

I started digging deeper and went through the “panther\UnattendGC\setupact.log” and the “debug\NetSetup.log”. It was here where I started to find some interesting issues.

We have an environment built around an OU structure based on location and computer type (desktop, laptop or virtual machine). The ComputerTypeOU property is saved in to a variable used in the Task Sequence. What OU the computer is added to is decided in the CustomSettings.ini-file. 

In both the setupact.log and NetSetup.log I found out that no value was saved in the “%ComputerTypeOU%”-variable.

NetSetup.Log of EliteDesk 800 G3 DM 35W

My initial thought was that the log prints the string without any value connected to the variable, but after going through the same logs on a newly installed computer, that had no issues joining the domain, I quickly found out that I was wrong. The variable should definitely contain the value generated by the CustomSettings.ini file.

NetSetup.Log of EliteBook Folio 9480m

As shown in the first image, the EliteDesk 800 G3 did for some reason not receive any value to this variable. I started going through logs once more, trying to find out why this computer was unable to fetch the required value.

Since we unfortunately do not have an OU named “%ComputerTypeOU%” in the domain, and the Join Domain-account was unable to create one, the computer did not join the domain because of the account used in our Task Sequence having insufficient rights.

But why this variable was missing its value was the main question. I started going through logs again, and this time I had something to look for instead of searching for the unknown. The BDD.log gave me a good overview of all the client properties. I compared a domain joined client with the EliteDesk 800 G3. Here I stumbled upon an interesting fact. The EliteDesk did not report as a laptop, a desktop nor a server, as shown below.

BDD.Log of a EliteDesk 800 G3 DM 35W

BDD.Log of a EliteBook Folio 9480m

 

Since the EliteDesk 800 G3 did not report any of the values needed for our structure, the solution was to add Model to the Priority list and associate EliteDesk 800 G3 with the “ComputerTypeOU”-property set to workstations.

After adding the Model property to the CustomSettings.ini file, the EliteDesk 800 G3 joined the domain flawlessly after running a Task Sequence.

This might not be the best solution to this matter, but it sure is a practicable fix. If anyone has a preferable solution, feel free to email me at johan.nilsson@xenit.se



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