Chris Nackers Blog

ConfigMgr and MDT Deployment Solutions

Useful Blogs

User Groups

October 2010 - Posts

Copy Content to Target Computers Using $OEM$ Folders

MDT 2010 supports using legacy $OEM$ folders to organize and copy supplemental files to the target computers. However, when deploying Windows Vista or later operating systems, data WIM files are preferred over $OEM$ folders.

Note   In an instance where multiple $OEM$ folders have been defined, the first driver that LTIApply.wsf finds is deployed to the target computer.

For more information about using:

·         Data WIM files or $OEM$ folders with Windows Vista or Windows Server 2008, see the Windows Automated Installation Kit User’s Guide in the Windows AIK.

·         An $OEM$ folder with Windows XP or Windows Server 2003, see the Microsoft Windows Corporate Deployment Tools User’s Guide (Deploy.chm) and the Microsoft Windows Preinstallation Reference (Ref.chm), both of which are in the Deploy.cab file in the Support\Tools folder on the Windows installation media.

MDT 2010 looks in the following locations within the deployment share, in the order specified, to find an $OEM$ folder:

·         Control\task_sequence (where task_sequence is the name or ID of the task sequence that MDT 2010 is installing). Create $OEM$ folders in this location to create a custom folder for each build.

·         Operating Systems\Name (where Name is the name of the operating system MDT 2010 is installing). Create $OEM$ folders in this location to create a custom folder for each operating system.

·         Platform (where Platform is either x86 or x64). Create $OEM$ folders in this location to create a custom folder for each platform.

·         $OEM$, which is at the root of the deployment share and is the default $OEM$ folder if a folder is not found in the previous locations.

An $OEM$ folder contains supplemental files. The following list describes each folder that you can create within an $OEM$ folder to organize these files:

·         $$. Windows Setup copies the contents of this folder to %SystemRoot% on each destination computer. It replicates all the folders, subfolders, and files that this folder contains in the %SystemRoot% folder of each destination computer. For Windows Setup to copy a file to %SystemRoot%\System32 on each destination computer, for example, put the file in $OEM$\$$\System32.

·         $1. Windows Setup copies the contents of this folder to %SystemDrive% on each destination computer. It replicates all the folders, subfolders, and files that this folder contains in the %SystemDrive% folder on each destination computer. This is typically drive C on most computers.

·         Drive. Drive is a drive letter (C, D, E, and so on). Windows Setup copies the contents of this folder to the root of the corresponding drive on each destination computer. It replicates all the folders, subfolders, and files that this folder contains in the corresponding drive during the setup process. For example, Windows Setup copies any files put in $OEM$\D to the root of drive D on each destination computer.

Microsoft recommends that these folders not be used. The folders rely on a very specific disk configuration on the destination computer. Use $1 to represent %SystemDrive%, instead. In most installations, $OEM$\$1 and $OEM$\C write to the same location: the root of drive C.

·         TEXTMODE. For Windows XP and Windows Server 2003, this folder contains hardware-specific files that Windows Setup and text-mode setup install on the destination computer during the text-mode phase of the installation process. These files may include OEM HALs, mass-storage device drivers, and the Txtsetup.oem file. The Txtsetup.oem file describes how to load and install these files. List these files in the [OemBootFiles] section of the answer file.

Show User Notification from Package or Task-Sequence

Read the article here.

Credit to Roger Zander for this nifty trick.

A way to show a simple user notification message from a Task-Sequence or a Software Package is to use the following command (as one line):

powershell.exe -command $a = New-Object -comobject SMSCliUI.UIEvents; $a.ShowMessage('User Notification', 'Please restart your computer...', 1)

The message will be visible even if the package runs with System privileges and the flag “Allow users to interact with this program” is not enabled.

New KB: Users may be unable to view and execute the System Center Configuration Manager 2007 reports hosted on SQL Reporting Services
Read the full post here.
Symptoms

Users may be unable to view and execute the System Center Configuration Manager 2007 reports hosted on SQL Reporting Services.
Problem 1: Trying to access http://<SQLServerName>/reports returns blank window. 
Problem 2: When trying to execute one of the reports you get the following error: 

An error has occurred during report processing. (rsProcessingAborted)

Cannot create a connection to data source '{5C6358F2-4BB6-4a1b-A16E-8D96795D8602}'. (rsErrorOpeningConnection)

For more information about this error navigate to the report server on the local server machine, or enable remote errors.

Cause

This can occur due to a lack of permissions on the Reporting Server and the Database.

Resolution

The basic configuration to allow an end user to view and execute the Configuration Manager Reports hosted via Reporting Services Point are as follows: 
1. Create a Global Security Group for users with Read access to the Reports.
2. Add all of the users to this group who need to access to the Reports. 
3. Open the Reports website with admin privileges (e.g. http://<SQLServerName>/reports).
4. Click on the Properties Tab > Click on New Role Assignment.
5. In the Group or User name box type in the domain\<GlobalSecurityGroup> you created in step 1.
This will allow those users to view the reports but will fail to execute them. They will get the error described in Problem 2.
To resolve Problem 2 follow the below steps: 
1. Add the Global Security Group in SQL using the SQL Server Management Studio Security > Logins > New Login > User Mapping.
2. Check the box for the SCCM DB and Check “db_datareader” role.

For the latest version of the article see the link below:

KB2428400 - Users may be unable to view and execute the System Center Configuration Manager 2007 reports hosted on SQL Reporting Services

OSD: How to add a script to a ConfigMgr 2007 Boot Image

One of the components of System Center Configuration Manager 2007 (SCCM 2007) Operating System Deployment (OSD) is boot images. Boot images in SCCM are really just WinPE images and are used during the operating system deployment process to boot computers so that an operating system can be loaded.

For more information about boot images and WinPE, see the following links:

What is Windows PE?

Planning for the Boot Image

Background

Typically, the standard boot images included in SCCM will provide enough functionality needed to deploy an Operating System, (outside of possibly adding drivers). In some cases, it may be required for administrators to have a script or a command run when the boot image boots and WinPE is started. As an example, one customer, due to specific network restrictions, had to run a command when WinPE started so that a specific route could be added in order for the client to reach the server. The customer created a batch file to run the command and configured WinPE to execute it at every start time, before WinPE started the task sequencing process.

Out of the box, it is not very straightforward to add such customizations to your boot images, so the purpose of this article is to provide information on how to add a batch file or command so that it is executed when your boot image starts.

As a note, there was an article provided in TechNet which describes the process of modifying WinPE to add a script or batch file so that it would be executed when WinPE started. Unfortunately, in SCCM, when boot images are updated so that drivers can be injected or settings are modified, the update process is automated so there isn’t an opportunity to make other customizations. The article I am referring to is http://technet.microsoft.com/en-us/library/cc766521(WS.10).aspx, which provides three ways to add a command to WinPE. The first two methods, using Winpeshl.ini, or Startnet.cmd, don’t work in SCCM. The third method, creating an unattend.xml, will work fine.

This article describes how to create an unattend.xml so that specific commands or scripts can be executed every time your WinPE boot image starts.

Read the full post here.

Error “The WebDAV server extension is either not installed or not configured properly” in Configuration Manager 2007

In addition the the following article:

TechNet post here.

It looks like if you see this in your logs:

401 WebDav Authorization OSD MDT GetDirectoryListing oDavRequest.GetDirectoryListing

Then the webdav_schema.xml is also the culprit. Use the fix below to resolve it.  

Issue:

The SMS Site Component Manager fails to install the SMS_MP_CONTROL_MANAGER component on a Windows Server 2008 based computer.  The error is as follows:

The WebDAV server extension is either not installed or not configured properly.
Solution: Make sure WebDAV is installed and enabled. Make sure there is an authoring rule that allow “All users” read access to “All content”. Make sure the WebDAV settings “Allow anonymous property queries” and “Allow property queries with infinite depth” are set to “true” and “Allow Custom Properties” is set to false.

If you go to the IIS management console, connect to the local server and open the “WebDAV Authoring Rules” option you will find everything enabled but it still doesn't seem to recognize it.

Cause:

This can occur if the settings for the WebDAV Authoring Rules become out of sync with the WebDAV_schema.xml file.

Resolution:

We need to go the location of the configuration file of Webdav which isC:\Windows\System32\inetsrv\config\schema\WebDAV_schema.xml. After opening this file you may notice that the settings in this file were different from the settings that were configured in the IIS Manager.  The settings were configured as:

<attribute name=”allowAnonymousPropfind” type=”bool” defaultValue=”false” /> 
<attribute name=”allowInfinitePropfindDepth” type=”bool” defaultValue=”false” /> 
<attribute name=”allowCustomProperties” type=”bool” defaultValue=”true” />

However they should be:

<attribute name=”allowAnonymousPropfind” type=”bool” defaultValue=”true” /> 
<attribute name=”allowInfinitePropfindDepth” type=”bool” defaultValue=”true” /> 
<attribute name=”allowCustomProperties” type=”bool” defaultValue=”false” />

After correcting these settings (remember we have to take ownership of the file to be able to change it) and restarting the World Wide Web Publishing Service and the SMS_SITE_COMPONENT_MANAGER the Management Point should install correctly. You can check if the installation is successful in the log fileMPSetup.log in your SCCM\Logs directory. If successful the log should have entries similar to this:


<04-01-2010 13:15:58>         ======== Completed Installion of Pre Reqs for Role SMSMP ======== 
<04-01-2010 13:15:58> Installing the SMSMP 
<04-01-2010 13:15:58> Passed OS version check. 
<04-01-2010 13:15:58> IIS Service is installed. 
<04-01-2010 13:15:58> checking WebDAV configuraitons 
<04-01-2010 13:15:58>  WebDAV is configured 
<04-01-2010 13:15:58> No versions of SMSMP are installed.  Installing new SMSMP. 
<04-01-2010 13:15:58> Enabling MSI logging.  mp.msi will log to E:\SCCM\logs\mpMSI.log 
<04-01-2010 13:15:58> Installing E:\SCCM\bin\i386\mp.msi CCMINSTALLDIR="E:\SMS_CCM" CCMSERVERDATAROOT="E:\SCCM" USESMSPORTS=TRUE SMSPORTS=80 USESMSSSLPORTS=TRUE SMSSSLPORTS=443 USESMSSSL=TRUE SMSSSLSTATE=0 CCMENABLELOGGING=TRUE CCMLOGLEVEL=1 CCMLOGMAXSIZE=1000000 CCMLOGMAXHISTORY=1 
<04-01-2010 13:16:32> mp.msi exited with return code: 0 
<04-01-2010 13:16:32> Verifying CCM_CLIENT virtual directory. 
<04-01-2010 13:16:32> Website path is IIS://LocalHost/W3SVC/1. 
<04-01-2010 13:16:32> Connecting to IIS. 
<04-01-2010 13:16:32> CCM_CLIENT is currently E:\SCCM\Client. 
<04-01-2010 13:16:32> Installation was successful.

Note:  As you do any time you modify an XML file, please make a backup of WebDAV_schema.xml before making changes to it.

As an alternative resolution you can also run the following commands:

C:\Windows\system32\inetsrv\appcmd.exe set config "Default Web Site/" /section:system.webServer/webdav/authoring /enabled:true /commit:apphost

C:\Windows\system32\inetsrv\appcmd.exe set config "Default Web Site/" /section:system.webServer/webdav/authoringRules /allowNonMimeMapFiles:true /commit:apphost

C:\Windows\system32\inetsrv\appcmd.exe set config "Default Web Site/" /section:system.webServer/webdav/authoringRules /+[users='*',path='*',access='Read'] /commit:apphost

C:\Windows\system32\inetsrv\appcmd.exe set config "Default Web Site/" /section:system.webServer/webdav/authoring /fileSystem.allowHiddenFiles:true /properties.allowAnonymousPropfind:true /properties.allowInfinitePropfindDepth:true /properties.allowCustomProperties:false /commit:apphost

Then just restart the World Wide Web Publishing Service and the SMS_SITE_COMPONENT_MANAGER and the Management Point should install correctly.

Ramp Up - Implementing System Center Operations Manager 2007 R2

Microsoft System Center Operations Manager 2007 R2 uniquely enables customers to reduce the cost of data center management across server operating systems and hypervisors through a single, familiar and easy to use interface. Through numerous views that show state, health and performance information as well as alerts generated according to some availability, performance, configuration or security situation being identified, operators can gain rapid insight into the state of the IT environment, and the IT services running across different systems and workloads. In this Ramp Up module, you will learn how to install, implement and administer Operations Manager 2007 R2.

Ramp Up - Implementing System Center Operations Manager 2007 R2

Microsoft Deployment Toolkit: Add/Remove WinPE Boot.wim Files To A USB Flash Drive Tool

Keith over at Xtreme Consulting has created a nice wizard driven tool for adding boot images to a USB flash drive.  This is designed to work with MDT 2010.

Read the full post and download the tool here.

Excellent work Keith!

You cannot use the ImageX.exe tool as a backup tool on a Windows Vista-based computer

This article describes the reasons why you cannot use the ImageX.exe tool as a backup tool on a Windows Vista-based computer. The ImageX.exe tool ships as part of the Windows Automated Installation Kit (WAIK).

You can use the ImageX.exe tool to capture an operating system installation image on which you have run Sysprep (Sysprep.exe) from the Windows Preinstallation Environment (Windows PE). You can then deploy the operating system installation image on another computer.
Although the ImageX.exe tool may appear to be a mechanism to create an image of a computer for backup, there are several issues that prevent using the ImageX.exe tool as a supported backup mechanism.
The following are the issues when you use the ImageX.exe tool as a backup mechanism:

  • Extended attributes are lost.
  • The ImageX.exe tool only applies reparse points that are symbolic links or junctions.
  • Sparse files on the system are captured and applied. However, the sparse files are no longer sparse after they have been applied.
  • Object IDs on files are lost in the capture process or in the apply process.

APPLIES TO
  • Windows Vista Ultimate
  • Windows Vista Enterprise
  • Windows Vista Business
  • Windows Vista Home Premium
  • Windows Vista Home Basic
  • Windows Vista Starter
Microsoft Deployment Toolkit Lite Touch (LTI) - “The Task Sequence Has Been Suspended”

image

This is basically the result of the the system coming up in an OS it didn’t expect.  For example WinPE instead of XP/Win7.  Commonly, you might be testing and have restarted the box in the middle of the Task Sequence running. Or perhaps you did a deployment and didn’t click “Finish” on the summary screen. 

The appropriate action is to either click “Finish” or reboot into the appropriate OS.  You can also hit F8 at this point and format the drive and then restart or manually kick off the Lite Touch process again. 

If you want an automated way to deal with this, which is most likely unsupported, read on! 

Normally when you click “Finish” the Task Sequence will exit and clean up after itself.  There is a script called LTICleanup that runs.  What we came up with at a recent client of mine, was developed for a lab environment. To avoid this pesky screen, we added the LTICleanup script to to the WinPE load process to automatically clean up the drive for us every time we load WinPE.  The obvious advantage is that we will never seen the above error.  However you will also lose all your log files if you just had a failed deployment.  To counter that,  I always recommend you take advantage of SLShare (logs copied at end of deployment) and SLShareDynamicLogging (logs copied during deployemnt) so that you have copies of what happened and can still troubleshoot the process. See the MDT documentation for more information on these properties.

First what you need to do is pull the unattend.xml from the boot image.  You will need one for each architecture x86 and x64.  You can use imagex to mount the litetouchpe_x64 or litetouchpe_x86 and then extract the unattend.xml. 

Once you have this, you will want to place it in your Extrafiles directory.  This allows us to make changes without having to manually mount the boot media everytime. When changes are made, the boot media will be updated and the unattend.xml injected into the boot media. The unattend.xml will go in the root of your Extrafiles directory.

DeploymentShare\Extrafiles\x86\unattend.xml

DeploymentShare\Extrafiles\x64\unattend.xml

Next we need to open the unattend.xml with Windows System Image Manager. What you’ll see is that there is a RunSynchronous that calls the LiteTouch.wsf script to start the process. What we want to do is add a step right before that to call LTICleanup.wsf before LiteTouch.wsf attempts to load.

First change the Order to “2” on the existing step.

image

Next add a new step that calls LTICleanup.wsf

image

image

Do this for both the x86 and x64 unattend.xml files to ensure this process works on both platforms.  Now every time WinPE loads, it will first run LTICleanup, then it will launch the wizard.

x64

image

If you want to test this solution, just restart in the middle of a Task Sequence, and then immediately boot to WinPE. You should receive the welcome screen instead of the “This Task Sequence has been suspended” error message.

image

Smile

Microsoft Deployment Toolkit 2010 Lite Touch Providing a Wizard To Select The Deployment Share

There is actually a little known built-in feature for prompting you with a wizard screen to select the Deployment Share you want to connect to. There is actually a built in pane in the main deployment wizard that will only show up if you haven’t specified a DeployRoot value in bootstrap.ini

By default, if you don’t provide a DeployRoot value, then the wizard will pop up and allow you to manually specify the server location. 

image

If you create a LocationServer.xml and put that on your boot image, then the wizard will display a drown down list of the Deployment Shares you have configured in the xml file.  Here is a screenshot example.

image

You can see that I have 2 Deployment Shares to choose from in the drop down:

image

The tricky part that isn’t documented well is the LocationServer.xml file and what to do with it.  Here is the correct format for the xml file as per the MDT documentation.

<?xml version="1.0" encoding="utf-8" ?>

<servers>

    <QueryDefault></QueryDefault>

    <server>

        <serverid>1</serverid>

        <friendlyname>

          Deployment San Antonio

        </friendlyname>

        <UNCPath>\\TX-Server\DeploymentShare$</UNCPath>

    </server>
        <server>

        <serverid>2</serverid>

        <friendlyname>

          Deployment Madison

        </friendlyname>

        <UNCPath>\\WI-Server\DeploymentShare$</UNCPath>

    </server>

</servers>

This file needs to be added to the boot image.  The easiest and most flexible way of doing this is by using an “Extrafiles” directory.  The files added to this directory will be automatically added to the boot images when they are created or updated.  This is the same method you would typically use for adding something like Trace32 to your 32-bit boot image.

I typically create an Extrafiles directory in the root of the DeploymentShare, so:

DeploymentShare\Extrafiles

Then we need to add a Deploy\Control folder structure:

DeploymentShare\Extrafiles\Deploy\Control

The LocationServer.xml needs to be in this Control folder.

Next we need to configure our boot images to use this Extrafiles directory. Go to the Windows PE x86 (or x64) Settings tab under your DeploymentShare properties:

image

Next configure the path for the Extrafiles directory you created.

image

Next we need to configure bootstrap.ini to allow the wizard to come up.  Edit your bootstrap.ini:

image

You need to either remove or comment out your DeployRoot path that you have:

image

Next, update your DeploymentShare to rebuild your boot images. 

image

Next you can launch your boot media through PXE (remember to update the WDS boot images), CD/DVD, or a USB thumb drive.

image

We have our Deployment Shares to choose from. 

image

Once you select a share, you will be prompted for credentials to connect to that share.

image

After providing valid credentials, we see our Task Sequences to choose from. 

image

If we had chosen the other Deployment Share, then we would have only see the following Task Sequences available to us.

image

That’s it! Hope you find this information useful.

ConfigMgr Driver Management: A New Development

Michael Niehaus has a new blog post discussing a new KB released from Microsoft.  This KB allows you to import duplicate drivers into ConfigMgr. 

Link to Michael’s original post.

Here is a summary of the post:

As part of the “ConfigMgr Driver Management: The Novel” blog postings (see http://blogs.technet.com/b/mniehaus/archive/2010/04/29/configmgr-2007-driver-management-the-novel-part-1.aspx for the first part) and in various presentations I mentioned that most of the challenges with driver management in ConfigMgr stemmed from the way drivers are imported into the ConfigMgr driver store:  duplicate drivers are ignored, so they don’t get put into the specified categories or packages.  That’s where the PowerShell scripts came in: when a duplicate is encountered, the scripts take care of putting that existing driver into the right category and packages.

Well, the ConfigMgr team has made available a hotfix that changes the driver import behavior in the console, handling duplicates differently than before.  Depending on the driver scenario that you are using, this might be the solution that you need.

The hotfix is available for download from http://support.microsoft.com/kb/2213600.  It requires ConfigMgr SP2 (no dependency on R2 or R3, but it works fine with either), and should be installed on the site server and any machine running the admin console.  (Interestingly, this fix is provided as an MSI instead of the more typical EXE-based fix.)

Once the hotfix is installed, you’ll notice a change in behavior:  You’ll never see the console complain about a duplicate driver.  It will always say that the drivers were imported successfully, even if they were already present.  But how does it handle the scenarios that I had discussed?  Let’s review them:

  • Scenario #1:  “Auto Apply Drivers” without categories (“total chaos”).  This scenario is unaffected.
  • Scenario #2:  “Auto Apply Drivers” with driver categories.  Unfortunately, this one still doesn’t work quite as expected:  If you specify an additional category on a subsequent import, expecting that category to be added to the existing category list, that doesn’t happen.  Instead, the existing categories are replaced with the specified category.  (I’m trying to follow up on this one to see why this is the case.)
  • Scenario #3: “Apply Driver Package” with model-specific packages.  The fix does work well for this scenario:  Duplicates drivers aren’t ignored any more, they are added to the specified driver package.  So this becomes a very simple scenario (and you don’t need to use the “unique file” import workaround, which ends up bloating the driver store).
  • Scenario #3J, “Johan’s Method” using driver packages without importing drivers at all.  This scenario is unaffected.

So if you use model-specific driver packages and import all your drivers into the driver store, you will want to try out this fix to see if it makes things simpler for you.  For the other scenarios, you probably don’t need this fix.

Complete List of Configuration Manager Related KB’s

Cliff Hobbs has put together a nice list of Configuration Manager (ConfigMgr) related KB’s. 

http://faqshop.com/configmgr2007/trobshoot/tskbs.htm

Automatically remove computers from a collection and reset the last PXE advertisement flag after a Deployment has finished

Maik Koster posted a nice blog discussing the removal of computers from a collection after OSD has completed. This is especially handy if you are using his web service to drive your OSD process.

Read the full post here.

Two of the administrative tasks you often have to do after a SCCM based Deployment has finished is removing the computer from the OSD Collection it has been added to start the Deployment (you don’t really want to leave a computer in a collection with an active OSD advertisement, do you?), and to clear the last PXE Advertisement flag in cases the Deployment has been started via PXE.

The latter is mainly interesting for testing purposes, where you need to re-image the same computers over and over again. But it’s also helpful in cases where the initial Deployment failed. If the underlying problem has now been fixed the Tech (or End-user) might not be able to re-initiate the Deployment before you also cleared the last PXE advertisement flag of that computer. I understand that this has been created to avoid kind of a Deployment loop for computers configured to boot from network first. But as we also remove the computer from the collection there shouldn’t be any bad side-effect. And there is still the caching on the PSP.

Since Version 7.0 the Deployment Webservice (Download) supports a couple methods that let us remove a computer from a specific collection and also to clear the last PXE advertisement flag. So all we actually need to know is the current collection. The following is based on an idea from Richard Zuraff and Jason Scheffelmaer (give credit where credit is due ;-) ). They suggested to simply add the same custom variable to each OSD Collection and then just add the CollectionID to this variable. If the TS executes, this variable will be available for us and filled with the ID of the appropriate collection. This way we can use a generic approach to remove the computer from whatever collection is configured in this variable. Very easy to implement and support.

SQL Query To Show Program Flags

Thanks to John Nelson for this query:

 

DECLARE @ProgramFlags TABLE (
   BitFlag INT PRIMARY KEY,
   Meaning VARCHAR(128),
   Description VARCHAR(512)
)
INSERT INTO @ProgramFlags
VALUES
   (2 ,'USECUSTOMPROGRESSMSG','The task sequence shows a custom progress user interface message.'),
   (16      ,'DEFAULT_PROGRAM','This is a default program.'),
   (32      ,'DISABLEMOMALERTONRUNNING','Disables MOM alerts while the program runs.'),
   (64      ,'MOMALERTONFAIL','Generates MOM alert if the program fails.'),
   (128     ,'RUN_DEPENDANT_ALWAYS','If set, this program''s immediate dependent should always be run.'),
   (256     ,'WINDOWS_CE','Indicates a device program.  If set, the program is not offered to desktop clients.'),
   (1024    ,'COUNTDOWN','The countdown dialog is not displayed.'),
   (4096    ,'DISABLED','The program is disabled.'),
   (8192    ,'UNATTENDED','The program requires no user interaction.'),
   (16384   ,'USERCONTEXT','The program can only run when a user is logged on.'),
   (32768   ,'ADMINRIGHTS','The program must be run as the local Administrator account.'),
   (65536   ,'EVERYUSER','The program must be run by every user for whom it is valid. Valid only for mandatory jobs.'),
   (131072  ,'NOUSERLOGGEDIN','The program is only run when no user is logged on.'),
   (262144  ,'OKTOQUIT','The program will restart the computer'),
   (524288  ,'OKTOREBOOT','Configuration Manager restarts the computer when the program has finished running successfully.'),
   (1048576 ,'USEUNCPATH','Use a UNC path (no drive letter to access)'),
   (2097152 ,'PERSISTCONNECTION','Persists the connection to the drive specified in the DriveLetter property.  The USEUNCPATH bit flag must not be set.'),
   (4194304 ,'RUNMINIMIZED','Run the program as a minimized window.'),
   (8388608 ,'RUNMAXIMIZED','Run the program as a maximized window.'),
   (16777216      ,'HIDEWINDOW','Hide the program window.'),
   (33554432      ,'OKTOLOGOFF','Logoff user when program completes successfully.'),
   (134217728     ,'ANY_PLATFORM','Override check for platform support.'),
   (536870912     ,'SUPPORT_UNINSTALL','Run uninstall from the registry key when the advertisement expires.');
WITH cte AS (
   SELECT
      f.BitFlag,
      f.Meaning,
      (f.BitFlag & p.ProgramFlags)/f.BitFlag AS [Enabled],
      p.PackageID,
      p.ProgramName
   FROM
      dbo.v_Program p
      CROSS JOIN @ProgramFlags f
)  
SELECT
   PackageID,
   ProgramName,
   MAX(CASE BitFlag WHEN 2 THEN [Enabled] END) AS [USECUSTOMPROGRESSMSG],
   MAX(CASE BitFlag WHEN 16 THEN [Enabled] END) AS [DEFAULT_PROGRAM],
   MAX(CASE BitFlag WHEN 32 THEN [Enabled] END) AS [DISABLEMOMALERTONRUNNING],
   MAX(CASE BitFlag WHEN 64 THEN [Enabled] END) AS [MOMALERTONFAIL],
   MAX(CASE BitFlag WHEN 128 THEN [Enabled] END) AS [RUN_DEPENDANT_ALWAYS],
   MAX(CASE BitFlag WHEN 256 THEN [Enabled] END) AS [WINDOWS_CE],
   MAX(CASE BitFlag WHEN 1024 THEN [Enabled] END) AS [COUNTDOWN],
   MAX(CASE BitFlag WHEN 4096 THEN [Enabled] END) AS [DISABLED],
   MAX(CASE BitFlag WHEN 8192 THEN [Enabled] END) AS [UNATTENDED],
   MAX(CASE BitFlag WHEN 16384 THEN [Enabled] END) AS [USERCONTEXT],
   MAX(CASE BitFlag WHEN 32768 THEN [Enabled] END) AS [ADMINRIGHTS],
   MAX(CASE BitFlag WHEN 65536 THEN [Enabled] END) AS [EVERYUSER],
   MAX(CASE BitFlag WHEN 131072 THEN [Enabled] END) AS [NOUSERLOGGEDIN],
   MAX(CASE BitFlag WHEN 262144 THEN [Enabled] END) AS [OKTOQUIT],
   MAX(CASE BitFlag WHEN 524288 THEN [Enabled] END) AS [OKTOREBOOT],
   MAX(CASE BitFlag WHEN 1048576 THEN [Enabled] END) AS [USEUNCPATH],
   MAX(CASE BitFlag WHEN 2097152 THEN [Enabled] END) AS [PERSISTCONNECTION],
   MAX(CASE BitFlag WHEN 4194304 THEN [Enabled] END) AS [RUNMINIMIZED],
   MAX(CASE BitFlag WHEN 8388608 THEN [Enabled] END) AS [RUNMAXIMIZED],
   MAX(CASE BitFlag WHEN 16777216 THEN [Enabled] END) AS [HIDEWINDOW],
   MAX(CASE BitFlag WHEN 33554432 THEN [Enabled] END) AS [OKTOLOGOFF],
   MAX(CASE BitFlag WHEN 134217728 THEN [Enabled] END) AS [ANY_PLATFORM],
   MAX(CASE BitFlag WHEN 536870912 THEN [Enabled] END) AS [SUPPORT_UNINSTALL]
FROM
   cte
GROUP BY
   PackageID,
   ProgramName

Unable to Publish Updates using SCUP - Exception occurred during publishing

Was having some trouble getting SCUP to publish updates on my lab today and this TechNet post solved my issue.

Read the full post here.

I was talking to my buddy Clifton Hughes today and he mentioned an interesting issue that we've seen a couple times concerning an error you get when trying to publishing updates to WSUS via System Center Update Publisher.  In this particular case, when you try to publish an update you would get the following error in the UpdatesPublisher.log:

Publish:  : Exception occurred during publishing: Verification of file signature failed for file: \\<serverName>\UpdateServicesPackages\<AppName_abf10b91-bfa6-44ff-aa54-099e4bf1487d\a7f3d4b2-02b6-4f0c-ab9b-e38c8de9c3f0_1.cab

You may also see this error:

"Exception occurred during publishing: Verification of the signature failed for fil" for each of the updates attempted.

To resolve this one, add the self-signed WSUS certificate to the Trusted Publishers Store and the Trusted Root Certification Authorities store on the Update Publisher machine as follows:

1.             Click Start, click Run, type MMC in the text box, and then click OK to open the Microsoft Management Console (MMC).

2.             Click File, click Add/Remove Snap-in, click Add, click Certificates, click Add, select Computer account, and then click Next.

3.             Select Another computer, type the name of the update server or click Browse to find the update server computer, click Finish, click Close, and then click OK.

4.             Expand Certificates (update server name), expand WSUS, and then click Certificates.

5.             In the results pane, right-click the desired certificate, click All Tasks, and then click Export.

6.             In the Certificate Export Wizard, use the default settings to create an export file with the name and location specified in the wizard. This file must be available to the update server before proceeding to the next step.

7.             Right-click Trusted Publishers, click All Tasks, and then click Import. Complete the Certificate Import Wizard using the exported file from step 6.

8.             If a self-signed certificate is used, such as WSUS Publishers Self-signed, right-click Trusted Root Certification Authorities, click All Tasks, and then click Import. Complete the Certificate Import Wizard using the exported file from step 6.

9.             Right-click Certificates (update server name), click Connect to another computer, enter the computer name for the Updates Publisher computer, and click OK.

10.           If Updates Publisher is remote from the update server, repeat steps 7 through 9 to import the certificate to the certificate store on the Updates Publisher computer.

Once you do this you should be good to go.

A special thanks to Clifton Hughes and Vinay Pamnani for doing all the leg work in tracking this down and getting it documented.

Posted: Oct 04 2010, 02:11 PM by cnackers | with no comments
Filed under: , ,
More Posts Next page »