Microsoft MVP Renewal 2020-2021

I’m so Thankful, honored, and excited to receive the confirmation email (below) from the Microsoft Most Valuable Professional (MVP) Award team confirming my award renewal for the 2020-2021 year. This is my fourth consecutive award since receiving my first one on January 1, 2017. It has been a wonderful, exciting, fun, challenging, and rewarding experience with so many positive opportunities.

The MVP award has provided me with some great opportunities in terms of my career growth, skill development, and various avenues to give back and help others in the IT Professional community. I had been invited to speak and delivered technical and soft skill sessions at conferences such as Microsoft Ignite Orlando 2019, Midwest Management Summit (MMSMOA), MMS Jazz Edition (New Orleans), and most recently covered the international circuit at Microsoft Ignite The Tour in Milan (Italy), Johannesburg (South Africa), and Dubai (UAE). I was also scheduled to deliver sessions on behalf of Microsoft at Microsoft Ignite The Tour in Zurich (Switzerland), Mumbai (India), Bangalore (India), and Tel Aviv (Israel), however these events were unfortunately cancelled due to COVID-19. I have also delivered various webinars, guest and ghost blogged, joined some technical expert panelist, reviewed technical books, tested and evaluated software, provided technical expertise, guest on podcasts, moderated technical forums, and engaged with the community both in person and online.

This is my 4th MVP Award and I am very grateful and appreciative for this honor and for the various opportunities provided to me over time. Thank you very much to each and every one of you for making me successful in my efforts as a MVP, IT Professional, and community contributor, and for providing me with the valuable resources and networking opportunities. I could not have achieved any of the above without the support and encouragement from the community, my friends in the technology industry, people I look up to as mentors, my mentees who keep me on my toes, wonderful Program Managers at Microsoft, a few industry leaders, and last but not least my loving family. Thank you!

I would like recognize and give my special Thank you to:

* Cathy Moya
* Heather Poulsen
* Betsy Weber
* Rochelle Sonnenberg
* Scott Schnoll

* MVP Award Program

Please like & share:

ConfigMgr Reporting Error – UserTokenSIDs LDAP Server Unavailable

I recently switched to using my new-ish laptop (Lenovo P1) for my day-to-day technical work and decided I should redo my test lab in Hyper-V, particularly for my ConfigMgr / MEMCM / Intune testing and troubleshooting stuff. While I have been actively using my ConfigMgr site in my lab, I didn’t pay much attention to the built-in reports until very recently, when I discovered I had an issue as all the reports produced an error.

The Component Status in the Monitoring node of the ConfigMgr console indicated no issues with the Reporting Services Point Role.

The Site Status was lit up nice and green and indicated all was working fine with my ConfigMgr site.

When a report is run from the ConfigMgr console or SSRS, the following error is produced (see image above):

The DefaultValue expression for the report parameter ‘UserTokenSIDs’ contains an error: The LDAP server is unavailable. (rsRuntimeErrorInExpression)

The full error is provided below:

System.Web.Services.Protocols.SoapException: The DefaultValue expression for the report parameter ‘UserTokenSIDs’ contains an error: The LDAP server is unavailable.
at Microsoft.ReportingServices.Library.ReportingService2005Impl.GetReportParameters(String Report, String HistoryID, Boolean ForRendering, ParameterValue[] Values, DataSourceCredentials[] Credentials, ParameterInfoCollection& Parameters)
at Microsoft.ReportingServices.WebServer.ReportingService2005.GetReportParameters(String Report, String HistoryID, Boolean ForRendering, ParameterValue[] Values, DataSourceCredentials[] Credentials, ReportParameter[]& Parameters)

The DefaultValue expression for the report parameter ‘UserTokenSIDs’ contains an error: The LDAP server is unavailable.

Stack Trace:
at Microsoft.ConfigurationManagement.AdminConsole.SrsReporting.ParameterPresenter.GetParameters()
at Microsoft.ConfigurationManagement.AdminConsole.SrsReporting.ParameterPresenter.LoadParameters(IReport report, Collection`1 navigationParameters, IResultObject resultObject)
at Microsoft.ConfigurationManagement.AdminConsole.SrsReporting.ReportViewerPresenter.Worker_DoWork(Object sender, DoWorkEventArgs e)
at System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs e)
at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)

I tried several troubleshooting steps including the following:

1. Uninstalled the Reporting role from ConfigMgr
2. Uninstalled the SQL Reporting Services
3. Reinstalled SQL Reporting Services
4. Reinstalled the Reporting role in ConfigMgr
5. Changed the registry key: “HKEY_LOCAL_MACHINE/SOFTWARE/Wow6432Node/Microsoft/ConfigMgr10/
AdminUI/Reporting/ReportBuilderApplicationManifestName” from the value “ReportBuilder_2_0_0_0.application” to “ReportBuilder_3_0_0_0.application”
6. Edited the file:
“C:\Program Files (x86)\Microsoft Configuration
Manager\AdminConsole\bin\Microsoft.ConfigurationManagement.exe.config” and changed the 2 to a 3 in the two locations:
<add key=”10.0″ value=”ReportBuilder_3_0_0_0.application”/>
<add key=”DEFAULT” value=”ReportBuilder_3_0_0_0.application”/>
7. Checked accounts including the service account for SQL reporting

None of the above steps helped fix the UserTokenSIDs issue. I searched high and low on Google / Bing and did not discover anything regarding “LDAP server is unavailable” specifically relating to UserTokenSIDs. I finally got the big guns out and contacted my close friend, Garth Jones, who is a known industry expert with SQL and SSRS. He is a Microsoft MVP and also owns a company called Enhansoft which provides a subscription service for all things reports, which extends the reporting capabilities in ConfigMgr. Enhansoft also provides a free report as a giveaway each month.


With Garth’s help, the issue was quickly discovered and fixed quite easily. Bottom line is that I was using a local administrator account (CM01\Administrator) to login to my ConfigMgr server as opposed to using a Domain account (Dhalico\Harjit) with the necessary privileges. FYI, “Dhalico” is my domain.
1. Added the Dhalico\Harjit account in the ConfigMgr console under
Administration > Overview > Security > Administrative Users (see image below)
2. Provided “Full Administrator” security role
3. Logged on to the ConfigMgr server as “Harjit” and tested running reports
4. Success! And Thank you Garth! 🙂

Please like & share:

How To Install ConfigMgr Client On VDI Template

The installation of the ConfigMgr client on workstations and servers is pretty straight forward, and can be done manually, with Client Push, and Software Update Based client installation to name a few. However, it is not as simple when dealing with Windows VDI systems, where extra steps need to be taken to avoid duplicate ConfigMgr client GUIDs and certificates on cloned VDI systems. Below are the steps to follow.

On the master or template system:

  1. Install the ConfigMgr client. Ensure it is properly functioning and has all the necessary components and actions.
  2. Stop the SMS Host Service. This can be done by launching the Command Prompt (CMD) as Administrator and running the following command:
    net stop ccmexec
  3. Delete the SMSCFG.ini file from the Windows folder location. In Administrator CMD, run the following command:
    del %WINDIR%\SMSCFG.ini
  4. Delete the SMS Certificates. To do this, launch PowerShell as Administrator and run the following command:
    Remove-Item -Path HKLM:\Software\Microsoft\SystemCertificates\SMS\Certificates\* -Force
  5. Remove the Inventory Action ID 1 in WMI. You can run the following command:
    wmic /namespace:\root\ccm\invagt path inventoryActionStatus where InventoryActionID=”{00000000-0000-0000-0000-000000000001}” DELETE /NOINTERACTIVE
  6. Once the above steps have been completed, shutdown the master template, capture a snapshot, and provision the VDI systems. At this point, each VDI system will generate a unique ConfigMgr GUID and will function as expected.

For step number 5, this can be achieved by using the wbemtest tool with the following steps:

  • Launch wbemtest as Administrator
  • Click Connect
  • Change the Namespace field as root\ccm\invagt, and click Connect
  • Click on Enum Classes
  • Select Recursive and click Ok
  • Scroll down and locate InventoryActionStatus, and double click
  • Click on the Instances button
  • Select the Inventory GUID and click Delete

Please like & share: