The Realm of the Verbal Processor

Jarvis's Ramblings

Domain Join Account – Minimum Rights

This falls under another one of those items that I have had in my private notes for a while, but can’t remember where I found it. When setting up the account in a ConfigMgr Task Sequence to join the new computer account to the domain, you must give that account rights in order for it to work. It is essentially a service account, so it should only be given the bare minimum rights. What are those rights? You can “Delegate Control” on the OU to the account and only give it “Allow” for the following:

Permission Apply To
Reset Password Computer Objects
Validated write to DNS host name Computer Objects
Validated write to service principal name Computer Objects
Read/Write Account Restrictions Computer Objects
Create/Delete Computer Objects This object and all descendant objects

Hopefully this will help others…and it will make it easier for me to quickly locate the next time I need to set it!

March 31, 2009 Posted by | ConfigMgr | 1 Comment

KB955955 Error

Update: I discovered that I made a mistake in the post below. Refer to this post instead. In particular, the possible solution I mention at the bottom of this post broke the ability of my Software Update Point to apply patches during the Build and Capture task sequence.

In my ConfigMgr virtual environment on my laptop I was implementing the KB955955 update today (this fixes an issue where there is a 90 second delay between installation of software packages in a task sequence). I used the instructions from the ReadMe.docx file that was part of the patch to modify the “Setup Windows and ConfigMgr” task in my task sequence. Essentially it says to put the following in the Installation Properties box of that step:


Once I did that, I ran a task sequence to test something else, but the task sequence bombed out before finishing. Once I checked the advertisement log, I could see that it failed on the “Setup Windows and ConfigMgr” task. I logged into the client machine that failed the Task Sequence, and looked for the log file for that failure. That log file is located at: “C:\Windows\System32\ccmsetup\LastError\client.msi.log”. Here is what that log file said (it’s a little long, but perhaps it will help someone else who is searching on this…

=== Verbose logging started:   Build type: SHIP UNICODE 4.00.6001.00  Calling process: C:\_SMSTaskSequence\OSD\SMS00006\ccmsetup.exe ===
Resetting cached policy values
Machine policy value ‘Debug’ is 0
******* RunEngine:
           ******* Product: C:\Windows\system32\ccmsetup\{35BE0386-E1B9-4F59-8DBD-E5B390AA8A09}\client.msi
           ******* Action:
           ******* CommandLine: **********
Client-side and UI is none or basic: Running entire install on the server.
Grabbed execution mutex.
Cloaking enabled.
Attempting to enable all disabled privileges before calling Install on Server
Incrementing counter to disable shutdown. Counter after increment: 0
Grabbed execution mutex.
Resetting cached policy values
Machine policy value ‘Debug’ is 0
******* RunEngine:
           ******* Product: C:\Windows\system32\ccmsetup\{35BE0386-E1B9-4F59-8DBD-E5B390AA8A09}\client.msi
           ******* Action:
           ******* CommandLine: **********
Machine policy value ‘DisableUserInstalls’ is 0
Setting cached product context: machine assigned for product: B3CBA12721F52334C9C01C4142FE66C6
Using cached product context: machine assigned for product: B3CBA12721F52334C9C01C4142FE66C6
SRSetRestorePoint skipped for this transaction.
Note: 1: 1402 2: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer 3: 2
File will have security applied from OpCode.
SOFTWARE RESTRICTION POLICY: Verifying package –> ‘C:\Windows\system32\ccmsetup\{35BE0386-E1B9-4F59-8DBD-E5B390AA8A09}\client.msi’ against software restriction policy
SOFTWARE RESTRICTION POLICY: C:\Windows\system32\ccmsetup\{35BE0386-E1B9-4F59-8DBD-E5B390AA8A09}\client.msi has a digital signature
SOFTWARE RESTRICTION POLICY: C:\Windows\system32\ccmsetup\{35BE0386-E1B9-4F59-8DBD-E5B390AA8A09}\client.msi is permitted to run because the user token authorizes execution (system or service token).
End dialog not enabled
Original package ==> C:\Windows\system32\ccmsetup\{35BE0386-E1B9-4F59-8DBD-E5B390AA8A09}\client.msi
Package we’re running from ==> C:\Windows\Installer\7bac5.msi
APPCOMPAT: looking for appcompat database entry with ProductCode ‘{CE6A85D8-D6B9-479A-9FE9-A06E56881E61}’.
APPCOMPAT: no matching ProductCode found in database.
Machine policy value ‘TransformsSecure’ is 0
User policy value ‘TransformsAtSource’ is 0
Note: 1: 2262 2: MsiFileHash 3: -2147287038
Unable to create a temp copy of patch ‘C:\_SMSTaskSequence\OSD\SMS00013\i386\hotfix\KB955955\SCCM2007AC-SP1-KB955955-x86.msp’.
Note: 1: 1708
Product: Configuration Manager Client — Installation failed.

Windows Installer installed the product. Product Name: Configuration Manager Client. Product Version: 4.00.6221.1000. Product Language: 1033. Installation success or error status: 1635.

MainEngineThread is returning 1635
No System Restore sequence number for this installation.
This update package could not be opened. Verify that the update package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer update package.
Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied.  Counter after decrement: -1
MainEngineThread is returning 1635
=== Verbose logging stopped:

Okay…there’s a problem installing the patch. I came across multiple references to a blog post that no longer exists ( I finally located the information elsewhere that states that to apply a patch like this during a task sequence, you need to follow a different process. Here are the basic steps condensed from the original post. (Thanks to Rod for the copy of the post.)

  1. Create a folder called “ClientPatch” under the Client folder in the ConfigMgr install directory. (e.g. d:\configmgr\client\ClientPatch)
  2. Copy the MSP file from the patch to that location. In this instance, the patch is located at d:\configmgr\Client\i386\hotfix\KB955955. (assuming that d:\configmgr is the installation directory)
  3. Update the DP for the ConfigMgr client package.

All installations should now use that patch as part of the installation. I haven’t actually tested this fully on my VM yet, but I will update this post if it does not work as indicated.

March 31, 2009 Posted by | ConfigMgr | 2 Comments