Configuration Manager Technical Preview 2106: Implicit Uninstall

Introduction

Oftentimes an IT administrator is concerned with getting an application ready for installation, without as much concentration on the application's uninstallation procedure.  And if the administrator has specified an uninstall command line then this might be in consideration for an application upgrade. Uninstall old version and install new version.  But most vendors are keen to have their applications easily upgraded and so their setup files will cater for the upgrade requirements as well as the new install requirement.  And sometimes an unattended uninstallation is more difficult to achieve than the installation.

Yes the focus is sometimes mainly on installation, however equal focus should be on the uninstallation.  Some applications are no longer fit for purpose, or their features have fallen behind their competitor's product, or the business model has changed and the application is no longer required, or the application presents a security risk to the organisation - in these situations the IT administrator needs an uninstallation process as robust as the installation process.

Microsoft's Configuration Manager product treats the uninstallation deployment the same way it treats the installation deployment.  It is just another command line to be executed on the user's device - and success or failure is determined by whatever condition has been created to flag a successful installation of the applications.  This could be a file or folder, or an MSI product code - when this installation condition fails for an the application uninstall deployment evaluation then, paradoxically, the uninstall deployment is a success.

Thus the administrator needs to spend as much effort on the management, administration and testing of the uninstall deployment as he or she does on the install deployment.  And this is not always a wasted expenditure because another reason for uninstalling a product may be to save on licensing expenses, or to free up a license, no longer required on a machine, so that another users can take make use of the license.

Microsoft has implemented the implicit uninstallation feature in the technical preview release 2106 of Configuration Manager.  This means that all we have to do is remove a device from a deployment's collection and, providing the deployment type contains a satisfactory uninstall command line, the application is going to uninstall itself without the administrator having to create an uninstall deployment.  

In this article I test this feature using the Sysinternals BGInfo64 tool as an example.  I create a deployment to install the tool to the primary site server system itself.  I then remove the system from the deployment's collection, force a machine policy retrieval, and observe the automatic uninstall of the tool.

The Sysinternals BGInfo64 Application

For my own testing I created a PSAppDeployToolkit package to install the BGInfo64 tool.  I like to use this handy wrapper toolkit for most of my packaging tasks - it provides a standard command line for all installations and all uninstallations, as well as a set of logs written to the Window\Logs\Software directory.  Thus I can easily determine if the application has actually started to install and the logs themselves help me with troubleshooting failures.  It is beyond the scope of this article to detail how this toolkit works or how to use it, however I can say it is very straightforward to learn.  You can download it at the following location.

https://github.com/PSAppDeployToolkit/PSAppDeployToolkit.git

Alternatively you can use use your own registered application for your testing.  If this is the case then you might want to skip to the section titled The BgInfo64 Deployment Configuration for an Implicit Uninstall, if your primary purpose is to learn about Implicit Uninstall and how to configure the deployment.

My package does the following when it is deployed as an installation.

1) Creates a Sysinternals folder at c:\program files\

2) Copies Bginfo64.exe and Pstools.chm files into the above directory

3) Creates a Bginfo64.lnk shortcut file to Bginfo64.exe at c:\users\public\desktop

My package does the following when it is deployed as an uninstallation.

1) Removes the Bginfo.exe file from c:\program files\Sysinternals

2) Removes the Bginfo64.lnk shortcut file to Bginfo64.exe at c:\users\public\desktop.

If you are familiar with the PSApp toolkit and would like to replicate my Bginfo64 PSApp package then you can do the following.

1) Download the Sysinternals tools from:

https://docs.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite

2) Extract the BGInfo64.exe and PStools.chm and copy them into the PSApp SupportFiles folder.

3) Edit the deploy-Application.ps1 script file to include the following in the Install section

New-Folder -Path "c:\program files\SysInternals"

Copy-File -Path "$dirSupportFiles\Bginfo64.exe" -Destination "c:\program files\SysInternals\Bginfo64.exe"

Copy-File -Path "$dirSupportFiles\Pstools.chm" -Destination "c:\program files\SysInternals\Pstools.chm"

New-Shortcut -Path "c:\users\public\desktop\Bginfo64.lnk" -TargetPath "c:\program files\sysinternals\Bginfo64.exe" -IconLocation "c:\program files\sysinternals\Bginfo64.exe" -Description 'Bginfo54' -WorkingDirectory "c:\program files\sysinternals"

4) Edit the deploy-application.ps1 file to include the following in the uninstall section.

Remove-File -Path 'c:\users\public\Desktop\Bginfo64.lnk'

Remove-File -Path 'c:\program files\SysInternals\Bginfo64.exe'

The BgInfo64 Deployment Type command line

Having created the PSApp BGInfo64 package I then registered it as an application in my Configuration Manager primary site, after upgrading it to version 2106.  The Deployment Type command line for the installation is standard:

Deploy-Application.exe -deploymenttype 'install'

The Deployment Type command line for the uninstallation is standard also:

Deploy-Application.exe -deploymenttype 'uninstall'

The BgInfo64 Deployment Type Detection Method Configuration

As stated above, the detection rule looks for the Bginfo64.lnk shortcut file in c:\users\public\desktop

The BgInfo64 Deployment Type User Experience Configuration

In my test package I select Install for system as the Installation behaviour.  I select Whether or not a user is logged on for the Logon requirement.  I select Normal for the Installation program visibility.  I then select Allow users to view and interact with the program installation tickbox.

The BgInfo64 Deployment Configuration for an Implicit Uninstall

Having created my PSApp toolkit package to install the Bginfo64 tool and having registered it in my primary site Technical Preview 2106 Configuration Manager instance as an application, and also having created the Deployment Type with the above configuration - the next steps are:

1) Create a collection and add the name of my primary site server into the collection as a Direct Rule.

2) Create a mandatory deployment to the collection with the option Uninstall this application if the targeted object falls out of the collection selected.

3) Force a machine policy by running the Machine Policy Retrieval & Evaluation Cycle action.

The Configuration Manager BGInfo64 package with Implicit Uninstall Executes

If you are testing your own application deployment then obviously the installation experience will be different.  My PSApp BGInfo64 package manifests itself with an install log at c:\windows\logs\software.  In addition, because I am logged onto the primary site server I am presented with the PSApp Deployment Toolkit wizard allowing me to defer the installation - and this is a rather handy feature and another good reason to use the wrapper for your packaging tasks.

I click on Continue and the installation completes.  As can be seen, a shortcut to Bginfo64.exe appears on the desktop, the Sysinternals directory is created in c:\program files and the bginfo64.exe along with Pstools.chm files are copied into this directory.  In addition the PSApp wizard thanks me for my patience and advises a reboot (not really required of course and you can customise this message as required).

I do click on OK but do not reboot my site server HyperV machine.  We can now test the implicit uninstall feature.

Testing the Implicit Uninstall feature in Preview Version 2106

Now we are in a position to test the Implicit Uninstall feature, and this requires us to remove the direct membership rule, for the targeted machine, from the targeted collection.  After this is done the following occurs:

1) Every 10 minutes a background worker process runs and detects devices the need to have implicit uninstall applications removed (because they have been removed from the install collection).  The activity of this worker process is written to the SMS_ImplicitUninstall.log file on the primary site server.

2) The client performs a computer policy download - by default this is every 60 minutes.

3) 15 minutes later the implicit uninstall application is uninstalled.

In my test I remove direct rule for my device from the collection so that it is now empty.

I then force a machine policy refresh action on the device.

We can see the event triggered in the SMS_ImplicitUninstall.log file

I then complete an Application Deployment Evaluation Cycle.

Note: this last action is not detailed as necessary in the release documentation however it was required in my testing scenario.

As can be seen above, the Bginfo64 shortcut file is removed and the PSApp uninstall log created - this verifies that the implicit uninstall feature has succeeded.

Summary

The implicit uninstall feature is a great new addition to the Configuration Manager product.  It simplifies the administration required to uninstall applications.  It reduces the number of collections in Configuration Manager thus reducing processing overhead.  Obviously care must be taken to ensure that devices are not accidently removed from installation collections.  I look forward to seeing this new feature implemented in the current release version of Microsoft Endpoint Configuration Manager.

I hope you enjoyed reading this article and I wish you similar success in your own testing environments.

Colin

Config Mgr 2105.2 - Device Custom Properties and the Administration Service

Introduction.

There is a lot of device data in Configuration Manager and this data can be used to target various systems with various management operations.  We may want to deploy a new driver to a particular Lenovo laptop model, for instance - and Configuration Manager should know about all the Lenovo laptops and what model number is relevant, and thus such an update task is very achievable. 

But what if we want to target an application to devices that belong to a particular cost center?  This requires a bit more thought and effort because the cost center property will probably not, unless you have extended HW inventory to pick up registry key or WMI instance values, be available as a property on those devices.

In technical preview release  2105.2, Microsoft has expanded the administration service so that it can be used to assign such non technical information to your site's devices.

What is the Administration Service?

It is beyond the scope of this article to delve under the hood of the administration service.  It is worth mentioning however that the administration service is similar in concept to the WMI service in that it provides a convenient way to programmatically direct the SMS Provider to do what you want it to do.  

Traditionally an SCCM administrator will have used VBScripts to create collections, distribute packages, delete machine entries, etc.  And in the last few years the SCCM administrator will have used PowerShell scripts because VBScripts are no longer the best tools for this work.

Ok so if we already have WMI to do all of this then why do we need the administration service as an alternative route to programmatic SCCM object management?  The answer is because the administration service provides API interoperability access over HTTPS, and this is convenient and necessary for internet based operations.  The administration service is a representational state transfer (REST) API.

For more information about the administration service see:

https://docs.microsoft.com/en-us/mem/configmgr/develop/adminservice/overview

For more information on how to set it up see:

https://docs.microsoft.com/en-us/mem/configmgr/develop/adminservice/set-up

Enabling the Service on your Test Primary Site

The good news, if you would like to begin your experimenting with the administration service - and you have the latest technical preview version of CM (2105.2 at the time of writing) is that the service is by default enabled.  All you really need to do, keeping it all simple, is enable enhanced https.  You can do this by navigating to Administration\Overview\Site Configuration\Sites.  Right click on your site and select Properties.  Click on the Communication Security tab.  Ensure that HTTPS or HTTP is selected and then check the Use Configuration Manager-generated certificates for HTTP site systems box is ticked.

In addition you may want to enable the Configuration Manager console to use the administration service.  In the same location and with your site selected, click the Hierarchy Settings icon in the upper ribbon.  Tick the option to Enable the Configuration Manager console to use the administration service.

Set a Custom Property on a device

In this example I will use PowerShell and the administration service to define a cost center property and value on a device.

In my technical preview Configuration Manager installation I do have a client named VM2468 active and healthy and registered to the database.  In the Configuration Manager console I navigate to Assets and Compliance\Devices and I right click on the VM2468 object and select Properties.  On the General tab I scroll down and take note of the Resource ID value - in this case it is 16777224.

In the top left hand corner of the Configuration Manager console I click on the down arrow and select Connect Via a Windows PowerShell, select A for Always Run when prompted.

The next thing for me to do is copy and execute each of the lines below into the PowerShell console.

$provider = "server2b.domain1.lab.tst"

$resourceID = "16777224"

$uri = "https://$provider/AdminService/v1.0/Device($resourceID)/AdminService.SetExtensionData"

$body = "{ExtensionData:{""CostCenter"":""S1234""}}"

[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true};

Invoke-RestMethod -Method "Post" -Uri $uri -UseDefaultCredentials -Body $body -ContentType "application/json"

The text in bold will need to be modified to suite your environment and requirements.

Viewing the extended property in a Configuration Manager  Query

Having added a CostCenter property with a value of S1234 to our device I can then create an SCCM query based on the following SQL statement

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_ExtensionData on SMS_G_System_ExtensionData.ResourceId = SMS_R_System.ResourceId where SMS_G_System_ExtensionData.PropertyName = "CostCenter" and SMS_G_System_ExtensionData.PropertyValue = "S1234"

I created a query named Cost Center with the above Query Statement.

And as expected when I ran the query, my machine whose NetBIOS name is VM2468, was returned in the result set.

And so this query can be used for the definition of a Configuration Manager collection to which management operations, such as application installations, can be directed.

View the SQL query in the SQL Server Profiler

Curious to see where this new data was actually located in the SQL database, I then ran the SCCM query while a SQL Server Profiler trace was running.

The Transact SQL query that is executed on the databases, when running the Configuration Manager Console query, is as follows:

select  all SMS_R_SYSTEM.ItemKey,SMS_R_SYSTEM.DiscArchKey,SMS_R_SYSTEM.Name0,SMS_R_SYSTEM.SMS_Unique_Identifier0,SMS_R_SYSTEM.Resource_Domain_OR_Workgr0,SMS_R_SYSTEM.Client0 from vSMS_R_System AS SMS_R_System INNER JOIN vSMS_G_System_ExtensionData AS SMS_G_System_ExtensionData ON SMS_G_System_ExtensionData.ResourceID = SMS_R_System.ItemKey   where (SMS_G_System_ExtensionData.PropertyName = N'CostCenter' AND SMS_G_System_ExtensionData.PropertyValue = N'S1234') OPTION(USE HINT('FORCE_LEGACY_CARDINALITY_ESTIMATION'))

So we can see that the custom property and value is to be found in the vSMS_G_System_ExtensionData view table.

Looking at the design properties of this view table we see that the custom data is stored in the ExtensionData table.

Thus running a simple query against this data we see our device whose resource id is listed as the InstanceKey value.

Conclusion

We have seen how the administration service can be used to easily add non device type properties, such as the cost center property, to a device that is registered in the Configuration Manager database.  In this example we used PowerShell to append the property and value to a device in an on-premise scenario.  This feature is a great bridge, allowing us to connect with data external to Configuration Manager and this is very useful for deployment targeting, collection building and also reporting.

I hope you enjoyed reading this article and I wish you the same success in your own testing,

MEM CM Technical Preview 2102 - Troubleshooting Collections with the View Relationships Tool

Introduction

The IT helpdesk worker gets a call complaining this or that application has not installed, even though the user has been informed the application has been deployed to the correct collection for the device.  The helpdesk worker knows that Configuration Manager is the agent, on the device, that is used to install the application. 

The helpdesk worker needs to do a few checks to determine why the application is not installed.

1) He or she may check the CM client is actually installed on the device.

2) He or she may check the CM service (named SMS Agent Host) is running on the device.

3) He or she may check the CM logs to ensure the machine policy process is taking place.

4) He or she may check that the Application Evaluation action has taken place.

4) He or she may check there are no firewall rules preventing the client communicating with the CM server components

5) He or she may check the CM cache is not full.

6) He or she may check that the application source files have been distributed to the correct distribution point server.

There may be some bespoke tools the helpdesk worker may use also to troubleshoot the failed application.  At some point however, having found no further issues - the helpdesk worker will need to ensure that the device is in the collection, to which the application has been deployed.

And then the penny drops - the device indeed is not in the collection.  And if this is the case - the device is never going to run the application.  Not until the issue is resolved, and the device name does appear in the collection - not until then will the application install on the device.

In this article I will step through the troubleshooting process - determining why a device is not in the collection it should be in.  I will use the new collection graphical feature introduced in SCCM 2010 to show how this new tool can indeed assist us with solving such an issue as this.

I will cover three necessary checks required in the collection membership examination process:

1) The collection membership rule is correct.

2) The device configuration meets the criteria defined by the collection membership rules.

3) The collection's dependencies and relationships to other collections is correct.

The Collection Membership Rule

I have a collection called Virtual Machines and I have a number of virtual machines in my MEM CM technical preview 2102 site.  My Hyper-V virtual machine, whose NetBIOS name is MDMClient1, should be in this collection - but it is not. I only have the one virtual machine in the collection, and this is in fact the MEM CM site server itself - server2b.

I  navigate to Assets and Compliance\Overview\Device Collections and highlight the Virtual Machines collection.  I right click on the collection and select Properties.

The Virtual Machines Properties windows appears with several tabs.  I will click on the Membership Rules tab.  Here we can see there is a rule called Virtual Machines.

I can then click on the Edit button (after highlighting the rule).

The next step is to click on Edit Query Statement.

If you are confident with using SQL or WQL expressions you will want to click on Show Query Language.  For this collection the WQL query is as shown below.

Highlighting the expression and a right click and a copy and paste reveals the total WQL query.  The important bit is the defining condition after the where statement:

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_COMPUTER_SYSTEM on SMS_G_System_COMPUTER_SYSTEM.ResourceId = SMS_R_System.ResourceId where SMS_G_System_COMPUTER_SYSTEM.Model = "Virtual Machine"

We see here that the collection is expecting a machine's model to have a value of  'Virtual Machine', if it is to be a member of the collection itself.

If you are not comfortable with WQL, rather than clicking on Show Query Language, you can click on the Criteria tab to determine the condition that is required, as shown below.

Now that we know the criteria for the collection membership we can then determine if the device configuration itself meets that criteria.

The device Configuration

In our example we do know that unless our device has a Model value of 'Virtual Machine', it will not appear in our collection.  How do we determine the exact model value for our machine?  There are a number of ways and I shall illustrate two of them.

Perhaps the easiest way is to click on Run, from the device itself, and then enter MSInfo32. The System Information tool appears and you can determine the WMI value for the Model in the right hand pane.

As can be seen, the value of Virtual Machine is listed and this is the correct value for our collection.  

Another way to retrieve the Model value is to use PowerShell, which seems to be the de rigueur way of doing things in the Windows world these days.

I do open up a windows command prompt with elevated privileges. I type in:

powershell.exe -executionpolicy bypass

After pressing Enter I have the PowerShell command interface ready to retrieve the model value.  I can retrieve this by typing in:

(Get-WmiObject -Class:Win32_ComputerSystem).Model

After pressing Enter I do have the Model value as shown.

Once more, using PowerShell, I have verified that the Model value is correct.  The next step is to check the collection relationships and dependencies. 

The Collection Relationships

Because we are using SCCM technical preview 2102 we do have the very useful Collection View Relationships tool.  This will help us to get to the solution to our problem - that is, the reason our virtual workstation is not appearing in our Virtual Machines collection. 

Firstly, using the CM console, we right click on the All Systems collection and select View Relationships

In my environment the tool presents two collection dependent pages.

Here is the graphical page one view.

And by clicking on the green arrow to the right I am taken to page 2.

The blue lines detail the limiting collection for each collection at a lower level from the All Systems collection.  We do know that unless a device is in the limiting collection for the bespoke collection we are analysing, the device itself cannot appear in our bespoke collection.

We can see from the graphical tool that the limiting collection, for our Virtual Machines collection, is the following collection: All Systems with CM client version 5.00.9045.1001.

And checking the criteria for this parent collection we confirm that indeed the Configuration Manager client needs to be on version 5.00.9045.1001.  This is the correct client version for the SCCM Technical Preview 2102 release.

Thus we can determine that we should check the CM client version on the client as a next step.  Unless the client version is correct, the device will not appear in the limiting collection and thus it will not appear in the bespoke collection itself - in this case the Virtual Machines collection.

On the client I do open the control panel and click on the Configuration Manager applet.

Here on the General tab I can see that indeed the Configuration Manager client version is correct.

We are still to get to the exact cause of our issue.  We know that the device should be in our bespoke collection but it is not.  So let us once more see if the View Relationships tool can provide us with another clue as to the reason for our dilemma.

The next thing I do is right click on my Virtual Machines collection and select View Relationships.  This gives me a graphical view of all the relationships for our bespoke collection.

We can see from this diagram that the immediate limiting collection, All Systems with CM client version 5.00.9045.1001, also has an Exclude relationship with the Developers Virtual Machines collection.  We know this is an exclude relationship from the Legend box that appears  to the upper right in the graphical tool. The grey dotted line is an exclude relationship.

Thus checking the properties off the Developers Virtual Machines collection I can see that my workstation device is actually added as a direct membership.

The penny drops:  because this is an Exclude limiting collection, and because my problematic device is in this exclude limiting collection - the problematic device is also filtered out of the bespoke Virtual Machines collection.  A possible solution therefore, is to remove the Direct Rule for my problematic device from the Developers Virtual Machines collection.

Having removed the direct rule and refreshing my bespoke Virtual Machines collection - my problematic device now appears in the Virtual Machines collection.

Conclusion

Hopefully I have shown in this article, how following a sensible set of checks and verifications, and by using the new Collections Relationships tool, we can eventually arrive at the cause of a failed application deployment.  In this case there was no failure as such, only a misunderstood relationship between a number of collections  - preventing our target collection from being populated with the device itself. 

I hope you have enjoyed reading this article and I wish you the same success in your own collection relationship analysis.

Colin

Community Hub Support for Application Content - CM Technical Preview 2012

Introduction

I have been working in the IT industry a long time.  Long enough to remember days when IT support staff would run up or down a flight of stairs, locate a user's desk, insert a floppy disk or a CD into his or her device and install the required application.  Of course this was time consuming but also prone to error - some applications need to be installed in a particular way.  One incorrect click and that application might not install or might not work as required.

And then I might come in, as a Systems Management consultant, install SMS or SCCM - and everything was a little easier and a little more efficient.  But there was always a gap between manager expectations and the reality of what the management product could deliver: and this was particularly so in terms of application deployment.  Sometimes this was due to the sales person miss selling the product, or perhaps the consultant not clearly detailing requirements and limitations.

You see the key thing here is that Configuration Manager is good at delivering an application's source files to a group of devices.  It is also good at executing a command line on those devices to install those applications.  But Configuration  Manager did not, and cannot, magically determine what that command line should be for each company's application deployment requirements.  Most companies have certain standards - some might prefer their employees to run through a wizard but most will want those applications installed silently without user input.  This means also the application can be installed outside of business hours and thus there is no deleterious impact on user productivity.

And some applications unfortunately will not install silently without a bit of engineering.  They might need to be part of a scripted installation, or they might require a string of undocumented parameters - and thus the IT discipline of 'packager' was born.  Quite often a packager may be required to create a customised installer file called an MSI file.  And even if a default installer file will complete the task, sometimes locating this file can itself be a challenge.  To this day packagers are still required by IT departments to ensure the application installations taking place are processed safely and in accordance with professional standards and best practises.

This does impact the IT budget and so Microsoft has implemented the ability to share application content and configuration requirements via the Community Hub.  You can download those published application definitions and files and quickly have them registered and deployable in your environment.  This feature is now available in Technical Preview 2012.  Let's see how this works in practise by downloading the System Center Updates Publisher app.

Using the Feature

On a Windows 10 device with the CM console installed and opened, the administrator will navigate to Community\Community hub.  From here, and from amongst the numerous community hub offerings, the administrator can locate the System Center Updates Publisher app.

The administrator can then click on the System Center Updates Publisher tablet to commence the download.

The administrator enters in the share location.

The app begins downloading.

The app content and configuration download completes. 

The administrator can then verify the installer file is in the defined location.

And finally the administrator can check that the package has been registered in SCCM with the appropriate deployment type configuration.

Conclusion

This new feature is a great addition to a great product.  In minutes I was able to register the System Center Updates Publisher app along with its source MSI file and all the required deployment type configuration.  I can then distribute the source content and deploy the app to the devices that require it.  Such an effort might be take between 1 and 10 days if I had to:

1) Download the installer file manually.

2) Research and determine the MSI parameter switches required for an unattended installation and uninstallation command line.

3) Register the app in SCCM.

4) Test the install and uninstall deployment type on a set of test machines.

Obviously the administrator is still required to perform all required testing and quality assessment requirements - but no one can argue that this new feature is very good and will be much used when it is implemented into the current production release of SCCM.

I hope you enjoyed reading this article and I hope you have similar success in your own testing and demonstrations.

Colin

Configuration Manager Technical Preview 2012 Community hub Console Extensions

Introduction

IT professionals might like to write a script or develop a report, that will work with Configuration Manager; and they might desire to do this themselves.  After all this is how an IT professional develops those skills that are in great demand in industry and commerce.  All too often however, deadlines and daily demands reduce this development time.  Microsoft knows this too well and thus they have integrated the community hub with Configuration Manager.  An IT administrator can leverage the efforts of those who have faced similar tasks, conquered those tasks, and published those achievements on the community hub.  You can then retrieve these products from within the Configuration Manager console and approve them for use in your site hierarchy.

In this article I will download and enable a Configuration Manager console extension.  This useful feature allows an administrator to right click on a Task Sequence Deployment and view status messages from devices that have run that assigned Task Sequence.

Feature Requirements

In order to access the community hub from within the SCCM console you will need Windows 10 build version 17710 or higher and .Net Framework version 4.6 or higher installed on the device from which you will run the console.

In addition, you will need to enable the SCCM site communication setting: "Use configuration Manager-generated certificates for HTTP site systems"

Enable the Configuration Manager console extension.

Open the SCCM console on your Windows 10 device and navigate to Community\Community Hub. A series of tablets for various downloadable SCCM add-on features will appear.

Click on All Objects and in the search bar type "show all status messages for a task sequence deployment".  Click on the search icon - the tablet for the Task Sequence status message add on appears.

When clicking on the tablet you are then presented with the option to Download the console feature.

It is then a matter of clicking on Download and the right-click Task Sequence Status Message viewing feature is installed in your SCCM console.

Using the new Right Click Status Messages Console Extension

Using the new feature is straight forward.  Navigate to one of your Task Sequences that has been deployed and executed by at least one client - Software Library\Overview\Operating Systems\Task Sequences.  Click on your Task Sequence and then click on the Deployments table at the lower portion of the console.  Right click on the deployment and click on Show Status Messages.

The Status Messages Set Viewing Period window appears.  Configure the time settings as required.

You then have access to the required status messages for your troubleshooting purposes.

I hope you enjoyed reading this article and I hope you have similar success in your own testing and demonstrations.

Colin