SCCM – Application Migration Failed Because of the Languages?

These days, I’m working on a SCCM migration which require to consolidate 5 ConfigMgr Sites into 1 Primary sites. So part of our transition plan, we want to shared the distribution points between our legacy environments and our new CM Site, then use the migration job to only migrate the objects that need to be migrated. Well So far nothing too complicated, but once we start the migration, we notice that some type of objects like application are failing…

So we look at the SMSProv.log and Migmctrl.log to check for any errors, but so far nothing to helpful (unkown error and 0/1 object returned);



So keeping working on the migration I start to think about what could be different between collections, packages and applications, as those are the 3 types of objects we have migrated so far.. and all the others are working well…

Having a closer look to the log files, I’ve noticed that the user context and preferred languages was set to English…


So I tried to remove all the other languages configure on the application that we are trying to migrate… then it works. So after removing the deployment type languages and Apps Catalog language the migration job work successfully…

I don’t know if this is something documented,as I haven’t been able to found anything related to this so far… but well now I need to work on a PowerShell script to do all the changes prior to the migration and reapplying the settings once the apps are migrated… Thx Microsoft.



SCCM – Microsoft Vulnerability Assessment Configuration pack in a Multi-Language Environment?

Recently, we have to deploy the Microsoft Vulnerability Assessment Configuration pack in our environment and this to meet some standards from our security team. First, we start following this guide from Enhansoft; which is excellent guide.

Of course, those baselines are really interesting from a security perspective, but one thing we noticed once start our deployment is … we got a lot of failure and this even using the bypass for PowerShell in our client settings. We start to troubleshoot the issue and it looks like some of the configuration items script are looking for specific value like Guest… So as we have to deal with a lot different languages, well it was just doesn’t work for us.


At this point my question was, why Microsoft doesn’t use the SID rather than the name in their CI script… So starting with this list of well known SIDs; , I’ve build my own script using PowerShell and user account SID. Ending with the following result;


So if you are in the same situation as me, here an example of the script I used to fix the Guest account status check (btw, make sure to copy the CI before you do some change);

$LocalAccounts = Get-WmiObject win32_useraccount -Filter “LocalAccount=’True'” |
?{$_.sid -match ‘^[S][-][1][-][5][-].*[-][5][0][1]$’} |
Select-Object Name,Disabled

foreach($Account in $LocalAccounts){
if($Account.Disabled -eq $False){Write-Host $($Account.Disabled)}

Hope that can help you to make those baselines work in your environment and Don’t forget to do some test before you target this to your production systems.

SCCM – Client health report for a specific computer

*** Update August 28: I have updated the RDL file and added the information for CM client 1606 . I’ve also added the required permission for the datasource***

In this post I will share with you a report that I’ve build to get all the information required for a specific computer. This report is divided in 4 different tables and here are the details;

  1. Operating System, in this table you will get all the information about the OS, such as display name, last reboot, etc. Specific_Comp_1
  2. Configuration Manager Client & AD, well this is a very interesting table that contains a lot of information, so in this table you get all the information about CM and AD sites, as well as all the information about the inventories,discoveries,policy request, MP, SUP, evaluation  and lastly the information about the collections, which can be expand to get the collection name. Specific_Comp_3
  3. System Information, in this table you will get all the information about the system, like computer Name & AD DN, Network, System drive, CM User Affinity and the next effective maintenance window.Specific_Comp_2
  4. Software Updates Information, in this last table you’ll get all the information about software updates (can be filter on vendors and classifications). Again, you’ll get information about the level of compliance, WUA version, missing updates and all the detail about the missing updates, like if they are targeted or not, etc.Specific_Comp_4

Alright, so now we need to discuss about requirements. First you need to add the Managed By attribute to your AD system discovery in configuration manager. Then you will also need to add the following properties to your hardware inventory, Logical_Disk — Free Space (MB) and Services — State, and finally but not the least you will need to create the following SQL function, Report for upcoming maintenance window.

Once the SQL function is created, you’ll now have to modify the SQL permissions (unless the reporting point service account already have db_datareader permission on the CM DB) and grant at least the Select permission on the 2 following SQL objects to your reporting service point account:


So here the link to get the RDL file: Client Health – Specific Computer



SCCM – Using Powershell to effectively set maintenance windows for Patch Tuesday

In this post, I will show you an example of how you can use to PowerShell to automatically set your maintenance windows for Patch Tuesday and overcome the limitations of the recurrence schedule… well in other term, make them work every months. This script is based on the one from Octavian Cordos that you can also found on Technet; Original Script

Ok so now let’s have a look the script. First it will look for all collections where the name match the following pattern, *SU_Server_Montlhy_Autoreboot_Day_*. Then it will take the last character as to set the Maintenance Window X  number of days after the patch Tuesday. i.e  (SCCM-SU_Server_Monthly_AutoReboot_Day_6 will have a MW set 6 days after). If needed you can change this pattern to match you need, and here is a example of what I have in place:


By default the script will create a maintenance window from 1:00 AM to 5:00 AM with no recurrence and it will also clean previous Maintenance Window. Note that you can change the time of the MW in the script by modifying those 2 variables and this to match your needs;



So here’s a quick recap:

  1.  The script will scan your collections based on their name
  2. All Previous Maintenance Windows that apply to the collections who match this pattern will be deleted
  3. A Maintenance Window (who apply to Software Updates deployment) will be created for all your collections (that match the pattern) X number of day after the Patch Tuesday based on the last character in the name of the collection.

Download the script : here

SCCM – Software Update Groups Compliance Dashboard Revisited, Part 2

In this second part, I will share with you some of the sub reports that I have created for the main SUG dashboard (Software Update Groups Compliance Dashboard Revisited). This will give you the ability to get the details for some of the tables in the dashboard and of course they can also be run independently, as they also bring a lot of useful information.

Let’s start with the first report, which is one of my preferred ones. It’s link to the Top Vulnerable Assets table and can be very useful as it gives you all the details about the health of a specific client as well as the level of compliance for Software Updates. The report contains 3 parameters, which are:

  • Computer Name
  • Vendor – List of vendor from the update catalog
  • Category – Update classification

and also contains multiple tables such as Operating System, CM Client/AD, System Info and Software updates information. Here are some screenshot of the reports:SysInfoDetailed_1


*** It may requires that you add some AD attributes (ManagedBy, DesktopProfile) to your CM system discovery as well as adding the service status to your client policy settings ***  

And now let’s have a look to the second one, which is link to the Assets Information table. Well this part is the only one in the Dashboard that contains the information for all clients, so not only the one with the agent. There are three filters available for this reports, which are:

  • Client – All, Unmanaged and Managed
  • Operating System – filter per OS
  • Collection – filter per Collection

and it contains a table with some information about clients, which can be useful to troubleshoot your client.


I will stop here for now, as you have the reports required to drill from the first two table of the Dashboard:SubReport_1So here’s the link to get these reports:

System health for a specific computer

System Health Overall

SCCM – Software Update Groups Compliance Dashboard Revisited

So first, it’s been a long time since my last post. So I hope it will be an interesting one for you guys… and yes, it is about custom software update report again.

In this blog post, I will share with you a Dashboard for Software Updates Group and it’s based on the ones created by Gary Simmons, which are just incredible. So for those who aren’t using it yet, here’s a link that I recommended to read first, as it explains in detail most of the feature include in this Dashboard;  SUG Dashboard from Gary Simmons

First, let’s talk about the parameters, in this Dashboard I’ve change the parameters to match our needs, so for that I’ve create a filter on the software update group parameter to only show the SUG that contains compliance in the name (This is use as a template containing all the updates that are required in our company).   Other fields like Company and Entity match our Folder Structure in SCCM and Scope is the collections that are within the second level folder SCCM. Here’s an example of what we use:


And finally the OS Type parameters allows to scope this report by OS Type, Servers, Workstations, etc. it the case that you have different OS in the Collection.


Ok, so in the first part of the Dashboard I’ve change the Asset table to include all devices and the ability to drill down to get the detailed information. Also, in this part I added 2 tables to first get the top 10 vulnerable systems and them the top 10 missing updates.


In the second part, I’ve added a custom Overall Systems Compliance part (again from a report from Gary Simmons) which contains all the OS Versions.



And lastly in the third part, I’ve added a chart to show the Compliance level per update severity, a chart about the updates scan status (% of success) and Errors details, a chart with the top 5 Windows Updates version and a table with the Software updates point status (last sync time, sync status).


here’s a link from where you can download this dashboard, in the case you are interested to try it;

SUG Compliance Dashboard

And in the next part, I will publish all the sub reports that I’ve create to drill down and get all the details information.

Part 2: Software Update Groups Compliance Dashboard Revisited, Part 2



SCORCH – Use Orchestrator to build a password expiration notifier tool

In this post, I’ll show you one of the possible ways on how we can use Orchestrator to build a password expiration notify tool. Based on this example, you will be able to customize how many days before the expiration that you would like to notify the users (you can use more than one policy) , use different template for the  password change reminder emails, set up different policies based on OU, etc… Of course, there are other ways to accomplish this task, such as PowerShell, but by using orchestrator, it will be very easy to extend the Runbook and add some features such as notifying the manager of the user, creating an incident in service manager when the password is expired, adding some logging/error handling, reused the same process for different tasks, such as account expiration and so on.

Ok, so before going further, here are some details on my environment;

  • Windows 2008 R2 domain and forest functional level.
  • Windows 2008 R2 DCs.
  • The service account use to invoke the child Runbook has the proper read permissions on AD users attributes.
  • The service account use to invoke the child Runbook has permissions to create table on a SQL Database.
  • Orchestrator Service account has Data Reader permissions the DB created by the PowerShell script.

Also, here are other things to consider;

  • If the orchestrator service account has the proper read permissions on AS users attributes, you do not need to invoke a child Runbook.
  • If you want to schedule the Runbook to run a custom schedule, you can use Orchestrator Schedule.
  • If needed, you can modify the PowerShell script to output some error and adding some condition in the Runbook to monitor those errors.

Ok, so here are the steps;

  • create the following variables in Orchestrator (and if defined, use your naming convention)
  1. SQLServerName =  “SQLServerName”
  2. SQLDBName = “SQLDataBaseName”
  3. SQLTableName = “SQLTableName”
  4. OUToMonitor = “OUDistinguishedName”
  • create new Runbook and use the following PowerShell script to the Import AD Data to SQL;



You can download the PowerShell Script to import AD data into SQL from here,


  • Configure the return value of the Runbook as;



  • Then create another Runbook with the following activites;



make sure to thick the check box, wait for completion and then configure it to invoke the first Runbook (make sure that the account use to invoke the Runbook have to proper AD and SQL permissions.)


add these conditions on the link


use this query to get the information from the database (in my example I will send  two reminder, so one 14 days before the expiration and the other 3 days.) And if needed, you can change the values in the where clause to match the your need. Also, add the SQLSERVERDBNameVariable from Orchestrator to the FROM clause.




those values should match the ones set in the SQL query WHERE clause and you also have to configure them for each of the reminder you want to implement.  (In my examples, I use two reminder)


again you have to configure this activity for all the reminders set in WHERE  clause of the SQL query.

And voila, at this point you have to configure the proper schedule then start the Runbook, and you should be good to test🙂 … and please make sure to test this before implanting this on a production environment.