Error 1639 during SCOM reporting installation

March 26, 2015

Hello Everyone,

A few weeks ago I experienced a bizarre issue during the installation of the SCOM reporting component. It kept rolling back the installation. When I took a closer look in the installation logs(default location: %systemdrive%\Users\%username%\Appdata\Local\SCOM\Logs) I noticed the last error before rollback was ‘Error 1639 Invalid Command Line Argument‘. This was strange because the wizard validated all my data throughout the steps. The next step I took was to install the reporting component through command line, however the same issue occurred: Invalid Command Line Argument.

After further analyzing the logs and comparing it with a successful installation log I noticed that the installer was unable to read the location of the data warehouse instance. First I thought it was an issue with security, but everything seemed to be fine in that regard.
I was unsure of where the installation took the data of the data warehouse location, as this was not a parameter that could be defined during installation. So I figured this had to be something that was read from the OperationsManager database. This reminded me that the port of the SCOM SQL instance was changed from dynamic to static a few days before.

This technet article describes what configuration changes are required for SCOM to work on a fixed port. The article requires you to change some DB records, one of which is the Data Warehouse location.

I knew of at least one mistake in this article. The table dbo.MT_DataWarehouse in which we need to change the record is not correct in most cases. This table only exists in SCOM 2007 or when you upgraded your SCOM environment from 2007 to 2012 for example. On a clean installation of SCOM 2012 and higher however, this table has been renamed to MT_Microsoft$SystemCenter$DataWarehouse.


But then I noticed another mistake in this article.

The article describes to change the DB record in this table from computer\INSTANCE1 to computer\INSTANCE1, <port>.
Notice the space between the comma and <PORT>.

I assume when this record is read during setup, the space causes the port to be seen as an additional command line parameter. When I removed the space from the records the reporting installation completed successfuly.

Hope this post helps some people out there!



Update Configuration Manager 2012 SP1 client with Cumulative Update 3

October 2, 2013

Hi all,

Today I’m going to talk about the Cumulative Update 3 of Configuration Manager 2012 SP1 and how to install the updated client to all Configuration Manager Clients. As you all might know this CU3 fixes some issues with Configuration Manager. For a detailed list, I recommend you to read the following Microsoft documentation:

First of all the CU3 should be installed on the primary site server.

The installation generates a couple of packages that should be appropriately deployed:

–          Package to update the console
–          Package to update the server
–          Package to update clients (x86)
–          Package to update clients (x64)

The focus today is on  the client update and how to get it installed throughout the environment.


We first have to look at the different deployment scenario’s:

–          Upgrade existing Configuration Manager Client (example for x86 clients)

1. Create a collection called All x86 Systems with client using the following query:

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.SystemType = “x86-based PC”

This collection has a limiting collection called “All Systems with Client”, this collection was created previously

2. Deploy the x86 client update to the “All x86 Systems with Client” collection using a required deployment

The same can be done for x64 clients

–          Integrating CU3 client with Operating System Deployment

In previous versions of SCCM when a cumulative update was installed, the update was added to the client installation source. Which means that the original client package only needed an update distribution points to include the update + add an additional parameter to the Setup Windows & Configmgr step in the task sequence.

Now the update is stored elsewhere, so a new client package should be created which contains the original client installation source and the cumulative update (.msp file)

1. Create an empty folder in your datastore where packages, applications, etc. are stored (eg. \\[fileserver]\DSL\Microsoft\SCCM_Client\2012_CU3\ML\MSI)

2. Copy the content from the installation folder of SCCM (eg. D:\Program Files\Microsoft Configuration Manager\Client into the new folder

3. Create an extra folder. Eg. Patches

4. Copy the contents of the folder where the update was installed (eg. D:\Program Files\Microsoft Configuration Manager\hotfix\KB2882125\Client) into the Patches folder

5. Create a package in Configuration Manager with the newly created folder as source (\\[fileserver]\DSL\Microsoft\SCCM_Client\2012_CU3\ML\MSI), No need to create a program for this package.

6. Copy the package to the distribution points available within your environment

7. Edit the task sequence where you want to apply the updated version of the Configuration Manager Client. Edit the existing “Setup Windows & Configuration Manager “ step and point it to the newly created package

8 Fill in the following command line at the installation properties field:



This is for the x86 client Operating Systems being deployed, for the x64 operating systems this is the right command line:


From now on clients being deployed with the edited task sequence will receive the latest version of the Configuration Manager Client

For future updates, the same way of working can be used.

Hope this helps!



SCCM 2007 + MDT 2010: Application in multiple roles

December 13, 2012


Today I had a little discussion about how MDT handles duplicate applications within roles. The environment consists of SCCM 2007 and MDT 2010 where MDT is used to store the configuration of client computers mainly to use MDT roles for software installation during task sequences.

The situation at that customer is that some applications can be member of multiple MDT roles which (I thought) would result in the fact that the application would also be installed multiple times. Let’s put this theory to the test.


–          3 roles:

  • Role 1: contains 23 applications
  • Role 2: contains 1 application
  • Role 3: contains 3 applications. All 3 applications are already member of Role 1 or Role 2

If MDT reacts to duplicate applications as I except I would see during the task sequence that all 27 applications will be installed. To see how many applications would be installed the ZTIGather.log can be checked on the client device during the execution of the task sequence.


When we open the logfile and check for the array containing all applications we expect to see PACKAGES001 up to PACKAGES027. But surprise was great when we only saw PACKAGES001 up to PACKAGES024. The difference is 3 which means that MDT has filtered out the 3 duplicate applications from role 3.

When checking the ZTIGather.log we can also see that the returned records count of the SQL query for all Packages in the Roles associated to the computer is 27.


This means that MDT detects that there are 27 applications in the 3 roles but at some point sees that there are a number of duplicates which are ignored while filling up the packages array.

Nothing can be found int the ZTIGather.log which states that the duplicates are ignored. That’s why I went deeper into investigating the ZTIGather.wsf script which contains all intelligence in processing the MDT data.

After some digging in the script I’ve found a function called QuerySQL which obviously will be used to get the right information from the SQL database and put it in the BDD.log. In that function there is a routine that processes the output of the SQL query.


While looking in more detail at the above code I noticed there is a line which has been put in comment stating:

“oLogging.CreateEntry “Value ” & oRS.Fields(cStr(sColumn)).Value & ” already found for ” & sElement, LogTypeInfo”

The statement ‘already found for’ made me suspicious so I’ve put this line of code out of comment and when I ran the script another time the ZTIGather.log showed the following output:


So basically the ZTIGather.wsf has the intelligence to detect duplicate applications, packages,… but doesn’t show this in the various logfiles, which is rather weird in my opinion.

I hope this gives you guys a better insight in how MDT handles applications.



Run Powershell script from software package

October 1, 2012


It might be really handy to run a Powershell script on your clients for doing a broad range of tasks.

In the past, vbscript was used to perform these tasks but considering to use powershell for the same tasks might be interesting

The big advantage of using Powershell is that it’s been built on top of .NET which means that it utilizes the base classes and is capable of interacting with some applications that cannot be manipulated using vbscript. Powershell also supports a wide range of cmdlets that facilitate tasks that might be difficult to perform when using vbscript.

Running a Powershell script using a package + program within SCCM 2007 ( or Configuration Manager 2012) can be done following the steps below:

  1. Create a package which contains the script you want to run eg. myscript.ps1
  2. Create a program for that package that sets the ExecutionPolicy of Powershell to unrestricted. This can be done by using this commandline: “powershell set-ExecutionPolicy Unrestricted -force” (without quotes)

  1. Create another program which runs the script that contains all the actions that need to be done on the client machines. In this example the command line should be: “powershell .\myscript.ps1” (again without the quotes). Be sure to add the “.\”-part because it doesn’t seem to run without that.

  1. Create a last program which sets the Executionpolicy back to restricted (or remotesigned) by using the commandline: “powershell set-ExecutionPolicy Restricted -force”  (once again without the quotes)

Now link the 3 programs together by using the “Run program first” checkbox from the program wizard in SCCM as follows:

  • Program mentioned at 4. has a run program first which points to the program mentioned at 3.
  • Program mentioned at 3. has a run program first which points to the program mentioned at 2.

As a final step create an advertisement (or deployment in ConfigMgr 2012) which uses the program mentioned at 4. and target all devices needed.

This should do the trick.

I can imagine there are other ways of achieving the same, feel free to comment with your opinion about this.

If you find this post useful, please consider buying me a virtual beer with a bitcoin donation: 3QhpQ5z5hbPXXRS8x6R5RagWVrRQ5mDEZ1



EDIT: Running a Powershell script should also be possible by using the following commandline as a program: “Powershell.exe -ExecutionPolicy Bypass -file .\myscript.ps1” (without quotes). This is a lot easier then using the 3 programs mentioned above, I’ll try and test this as soon as possible and get the result back at you guys.

EDIT2: the method of using “Powershell.exe -executionpolicy Bypass -file .\myscript.ps1” seems to work.

SCE 2010 Installation error: This instance cannot be used for the Essentials database

January 30, 2012

When will you be faced with this problem?

  • New installation of SCE 2010
  • WSUS is already installed using an existing SQL server standard for its database

Problem description

When installing System Center Essentials 2010 for a client I faced the following error: “This instance cannot be used for the essentials database because it does not contain the windows server update services database”.

As you all know, WSUS needs to be installed on the SCE server. I knew the instance hosted the WSUS database. The problem is, that the SCE installer looks at the following reg key to locate the database server that is used by WSUS:

  • HKEY_LOCAL_MACHINESOFTWAREMicrosoftUpdate ServicesServerSetupSqlServerName

When installing WSUS, it will enter the FQDN of the SQL server in this registry key. The SCE installer can only cope with the NETBIOS name, which results in the error above.

The solution

How to solve this issue? Replace the FQDN by the NETBIOS name in this registry key:

  • HKEY_LOCAL_MACHINESOFTWAREMicrosoftUpdate ServicesServerSetupSqlServerName

And now bye bye installation error!

Ow yes, do not forget to not select “use microsoft update or installation” further on in the wizard or the install will fail. Long live bug-free installers J.

Installation Service Manager 2012

January 11, 2012


Happy newyear and best wishes for 2012 ! Today I share the finding of the installation of Service Manager 2012 Beta.

Prereqs :

-> OS Windows Server 2008 R2 SP1

-> Service Manager 2012 Beta. Link :

-> SQL with correct collation and full text search installed.

Unpack the exe and run the X64 setup.

First we install the service management server.

Select the trial version and accept the license conditions.

Select the correct install path ( here the default path , no more additional disk space available 🙂

Install the missing requirements by using the wizard. Easy.

First One done.

Second one done.

Third one done.

Close the service manager setup and restart the wizard.Verify the result.

Select the SQL server and instance, the wizard will verify the SQL collation. See link : for the supported collations.

Select the correct path and click next. The beta always gave the incorrect collation although the collation was correctly set on this specific instance.

Select a unique management group name and a Service manager admin group.

Use the correct service account ( must be local admin on server )

Use the correct workflow account.

Check the CEIP.

Check recommend settings.


Check result.

Next time we configure the service desk tool. Bye.