Quae Nocent Docent

I encountered this problem while preparing a demo consisting in a migration from Windows XP to Windows 7. I was using USMT 4, MDT 2010 and SCCM 2007 SP2 RC. In my task sequence I used hard-links to capture user data from a Windows XP installation and then to restore data back after applying a Windows 7 Image previously created. The migration process completed successfully but no system component settings were migrated. I looked at the scanstate.log created in %systemroot%\system32\ccm\logs\SMSTSLog to see if something went wrong and I found the following line :

2009-10-17 17:19:44, Info [0x000000] Downlevel Manifests folder is not present. System component settings will not be gathered.

The error is related to a not present manifest folder, so I used FileMon lo verify in which location scanstate was looking :

Scanstate looked for that folder in %Systemroot%\system32, same location as the “Current Directory” of the process (as shown by Process Explorer).

By doing a simple search with Google I’ve found that I’m not alone and that other people experienced the same issue (http://systemcenterideas.com/2009/09/usmt-issues-with-mdt-2010). The fix proposed in that blog does not apply to me because I use a “Capture Task” and not a script to execute scanstate.

So while waiting to see if it will be fixed in RTM (I hope so) I needed a workaround.

I decided to create a wrapper that :

• executes a renamed scanstate.exe as a child process.
• passes the same parameters received from the command line to the child process
• passes the Application path as the Current Directory of the child process
• returns the child process exit code.

I used :

• GetCommandLine : to retrieve parameters passed to the wrapper
• GetModuleFileName : to get the application path (after eliminating the application file name)
• CreateProcess : to call the renamed scanstate and to pass the application folder as the Default Directory
• GetExitCodeProcess : to retrieve the child process exit code and to pass it to the task sequence.

I renamed scanstate.exe to _scanstate.exe and I putted my wrapper in the USMT x86 folder, naming it scanstate.exe.

As it can be seen in the previous picture, my wrapper calls the real scanstate application (named _scanstate.exe) as a child process and forces the “Current Directory” to be the same where the wrapper is located. With the correct “Default directory” _scanstate.exe is able to access the manifest folder.

This is a sort of hack, it is not supported an probably it is not the best solution to this problem, but in this case I’m running an RC version of SCCM 2007 SP2 and I’m only interested in have the demo working in the right way. I really hope that this will be fixed in the RTM version of SP2 or that if there is a supported alternative solution to this problem, that will be published soon (I know that I can copy manifest folder to the system32 before calling scanstate, but I don’t like to do that).

– Fabrizio

This posting is provided "AS IS" with no warranties, and confers no rights.

In a recent SCCM deployment I’ve been asked to produce some custom reporting. These are the kind of reports it’s not easy to develop with the standard SCCM reports (ASP based) and I always used SQL reporting Services (SRS) to give some extra value. This time, with SCCM SP1, I decided these reports needed to be integrated in the standard view in the admin console. Given the complexity of the reports I couldn’t use the SCCM Wizard. Initially I though this was going to be an easy job, it turned out to be pretty challenging.

My first try was to just add my custom reports under the root folder managed by SCCM SRS Point, I though “if they works in SRS they will in Admin Console as well”. Wrong.

SCCM manages SRS reports in its own way and they need to have a whole lot of prerequisites to render properly in SCCM. With this post I’ll try to detail the steps needed, the next stage will be to develop a script to automate all this work, but I won’t be able to share it with the community given my company policies.

Let’s start from the beginning. SCCM manages all the reports under a specified root folder, under this folder it creates a custom dataset (identified with a GUID). Every report created by the wizard uses this datasource in two ways, first it links the internal queries to the datasource and secondly it identifies the datasource with its guid. First lesson, to work properly, your reports must use the same data source and use the guid for the data source name in every dataset.

So if your datasource definition is like this

   1:     <DataSource Name="DS-SCCM">

   2:       <DataSourceReference>DS-SCCM</DataSourceReference>

   3:       <rd:DataSourceID>1e8624b9-87ae-4ea9-ac2a-9a56f7cb3f8b</rd:DataSourceID>

   4:     </DataSource>

It should be corrected to

   1:     <DataSource Name="{5C6358F2-4BB6-4a1b-A16E-8D96795D8602}">

   2:       <DataSourceReference>/ConfigMgr_RE0/{5C6358F2-4BB6-4a1b-A16E-8D96795D8602}</DataSourceReference>

   3:       <rd:DataSourceID>1e8624b9-87ae-4ea9-ac2a-9a56f7cb3f8b</rd:DataSourceID>

   4:     </DataSource>

Then every Data Source Name property in every dataset must be changed to the datasource guid

   1:         </QueryParameters>

   2:         <DataSourceName>{5C6358F2-4BB6-4a1b-A16E-8D96795D8602}</DataSourceName>

   3:       </Query>

When a report is rendered in Admin Console it is actually copied in a temporary folder (don’t ask me why). Second lesson, images need to be embedded in the report or absolute links must be used, corollary drill through reports need to be identified with an absolute path (Visual Studio always uses relative path for both).

So if this is the snippet created with Visual Studio

   1: <Action>

   2:     <Drillthrough>

   3:         <ReportName>MyReportDetail</ReportName>

   4:         <Parameters>

it should be corrected with an absolute path like this

   1: <Action>

   2:     <Drillthrough>

   3:         <ReportName>/ConfigMgr_RE0/Folder/MyReportDetail</ReportName>

   4:         <Parameters>

In the following pictures you can identify the SCCM datasource {5c6… and the temporary report folder bceb6…

The SCCM SRS viewer assumes the report has an header section, if not it will use an empty one. So you better define your own header and if you’re not going to use it just set the height property to 0.

The viewer assumes all the body controls have a <left> tag, if not it will use a default one. If you use Visual Studio to author SRS reports it will omit the <left> tag if the control is 0 aligned. I found a good compromise is to align all the body controls at 0.001in in Visual Studio.

Finally let’s talk about parameters, SCCM SRS viewer pretends to use it own UI for report parameters, alas:

• defaults are not set
• there’s not datetime calendar control (so you need to type the date / time value)
• for combo properties the Label properties is not set, so if the report needs to show the chosen parameter it must use the Value property or lookup once again the label (this was my case)

I didn’t find any documentation on how to integrate your SRS custom reports in SCCM, I hope these notes will help.

- Daniele

This posting is provided "AS IS" with no warranties, and confers no rights.