In your System Center Configuration Manager 2007 environment, you may find that a distribution point is not updating and a pck file may appear to be "stuck" or "locked" in the X:\Program Files\Microsoft Configuration Manager\inboxes\despoolr.box\received folder (where X: is the drive where ConfigMgr 2007 is installed) and the file is not able to be renamed or deleted even with the following services stopped:

• WMI
• SMSExecutive
• Component Manager
• BITS
• Antivirus

Cause

The file was locked by a service called dsmcsvc.exe which was from IBM Tivoli backup software (it was named TSM Scheduler in Services). It is possible other software could have a lock on the file as well, this is just one example.

Resolution

Using Process Explorer turn on the handles view (View menu, Lower Pane view, Handles) then from the Find menu, (Find Handles or DLL...) type in the file name that is locked (e.g. X:\Program Files\Microsoft Configuration Manager\inboxes\despoolr.box\received\filename.pck) and it should show you the service that has locked this file.  In this case we found it was locked by dsmcsvc.exe (IBM Tivoli backup software).  Stopping the TSM Scheduler service (dsmcsvc.exe) caused the packages to start processing again in the despoolr.log.

More Information

This problem could occur with other software locking a file and preventing a package from being updated.  Using Process Explorer is a useful way to determine what service has a lock on a file.

Hope this helps,

Clifton Hughes | Senior Support Engineer

Consider the following scenario in System Center Configuration Manager 2007 Service Pack 1 (SP1):

• You create a large package that is several gigabytes.
• You assign the package to a branch distribution point (BDP).
• You repeatedly change the package. Every time that you change the package, the package is updated on the BDP.

In this scenario, the changes are not updated on the BDP. This problem occurs randomly.

If you're experiencing this issue there's a new hotfix available to address it.  See the link below for details:

KB973762 - A package that is several gigabytes is not updated on a branch distribution point (BDP) in System Center Configuration Manager 2007 Service Pack 1

J.C. Hornbeck | System Center Knowledge Engineer

Update 2/1/2011 - There is now a SP2 hotfix that addresses this here:http://support.microsoft.com/kb/978021

=====

Consider the following scenario:

• You install the distribution point role on a Microsoft System Center Configuration Manager 2007 Service Pack 1 (SP1) site server.
• You customize the retry settings on the Distribution Point tab for the distribution point. Or, you use the default value for the retry settings.
• A retry is required after a package distribution fails.

In this scenario, the Distribution Manager does not honor the retry settings on the Distribution Point tab when the Distribution Manager retries the distribution.

Note Before each retry, there is a 10-second delay.

For information on the hotfix and associated settings needed to resolve this see the following new Knowledge Base article:

KB978875 - The Distribution Manager does not honor the "Number of retries" and "Delay before retrying (minutes)" retry settings on SCCM 2007 SP1 site servers

J.C. Hornbeck | System Center Knowledge Engineer

If you are using IIS 7 or IIS 6 with Kerberos Authentication, you may see an increase in network traffic and overall slow performance when pushing out large packages to your System Center Configuration Manager 2007 Distributions Points.   This can happen because the default behavior with this configuration is to authenticate every HTTP request, therefore by default you will see a HTTP GET request and then a 401 Authentication request from the server then another HTTP GET request with authentication.  In ConfigMgr 2007, if you are using a network access account this could increase Kerberos traffic to the DC as well, which in certain cases could negatively impact overall system performance. 

So what's the solution?  Session based authentication.  Below I demonstrate what the behavior looks like with Kerberos authentication and then I show how to make the changes so that IIS will use Session base authentication instead. This means that we will only ask for authentication once if it is in the same TCP/IP session.

You will notice in the Network Monitor trace below that we see each 401 response asking for authentication followed by a KerberosV5 packet response. In the initial request we send anonymous authentication which prompts the server to respond with a 401 Authentication required packet, and we then send a new request with authentication and that prompts the server to send a 206 response back which is successful. So the issue comes in when we have to process a lot of requests and each requires to be re-authenticated for the same TCP session:

This is a breakdown of the KerberosV5 packet you see above to show that it is actually the HTTP status code 206 response.

Note: For more information on this behavior see the following Knowledge Base article:

KB954873 - You may experience slow performance when you use Integrated Windows authentication together with the Kerberos authentication protocol in IIS 7.0

To resolve this problem when using IIS 7.0 set the value of the authPersistNonNTLM property to True at the server level. To do this, follow these steps:

1. Click Start, click Run, type cmd, and then click OK.

2. At the command prompt, type the following commands, and then press ENTER:

cd %SystemRoot%\System32\inetsrv
appcmd set config /section:windowsAuthentication /authPersistNonNTLM:true

Note: The authPersistNonNTLM property controls the reauthentication requirement of Kerberos authentication. By default, this property is set to False.

After you set the authPersistNonNTLM property to True, you do not require authentication for every request that is made over the same keep-alive connection. You may have to authenticate again if you use a different client TCP port to make another HTTP request. This scenario occurs when a new HTTP keep-alive session must be established.

For more information about HTTP keep-alive sessions, visit the following Internet Engineering Task Force (IETF) Web site:

http://www.ietf.org/rfc/rfc2616.txt

The authPersistNonNTLM configuration property in IIS 7.0 replaces the EnableKerbAuthPersist registry key that is used in IIS 6.0:

KB917557 FIX: You may experience slow performance when you use Integrated Windows authentication together with the Kerberos authentication protocol in IIS 6.0

To resolve this problem when using IIS 6, set the value of the EnableKerbAuthPersist property to 1 at the server level. To do this, follow these steps:

1.     Click Start , click Run , type regedit , and then click OK.

2.     Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters

3.     On the Edit menu, point to New , and then click DWORD Value.

4.     Type EnableKerbAuthPersist for the entry name, and then press ENTER.

5.     Right-click EnableKerbAuthPersist , and then click Modify.

6.     In the Value data box, type 1 or any nonzero value to enable the hotfix, and then click OK.

Note: To return the IIS service to the default behavior, set the value to 0.

7.     Exit Registry Editor.

8.     Restart the IIS service. To do this, follow these steps:

a.     Click Start , click Run , type cmd , and then click OK .
b.     Type the following commands. Press ENTER after each command:

net stop iisadmin
net start iisadmin

Once you make the change in IIS you will notice in the screenshot below we see the HTTP 401 Response followed by Kerberos then we no longer see the 401 any more until the TCP session changes. This will cut the amount of request and responses in half and will also improve performance:

The last time I saw this issue, where we saw the poorest performance was on the Domain Controller. When a large software distribution package was released to over 5000 clients we saw a significant performance issue on the Domain Controller. Taking the Netmon trace, we could trace it back to Network Account being used in SC Configurations Manager. For each and every one of the 401 requests we saw the client sent Kerberos AS_REQ and KRB_TGS_REQ for the Network account (in my lab I used ‘smsuser’).  During the time, when we pushed out the software distribution package to 5000 users we were seeing 180 requests per sec on the Domain controllers.

Once we changed to session based security the performance issue was alleviated.

Louis Hardy | Senior Support Escalation Engineer

Microsoft Configuration Manager 2007 setup on Windows Server 2008 may fail to proceed with the following error message:

Web-based Distributed Authoring and Versioning (WebDAV) is required for the management point and distribution point site system roles. If you have selected to install a site role requiring WebDAV, and it is not enabled, this rule will fail. Web-based Distributed Authoring and Versioning (WebDAV) is not enabled and/or IIS 6 WMI compatibility component for IIS7 is not installed on the computer specified for management point installation or setup was unable to verify remote IIS settings because IIS common components were not installed on the site server computer. ConfigMgr requires WebDAV to be installed and enabled in Internet Information Services (IIS) for management point site systems. Setup cannot continue.

This occurs even if the steps from How to Configure Windows Server 2008 for Site Systems article has been followed.

This can occur if WebDAV has been configured at the global level rather than at the default web site level.  Even if the settings are the same at both levels, setup requires that only the individual web site settings are configured.  Configuring the same settings at both levels will not allow setup to proceed, since global settings in this case are not written to the <webdav> section of the default web site in ApplicationHost.config (since they are effectively the same, there is no reason to write them twice).

To resolve this issue and allow ConfigMgr 2007 setup to complete follow the steps below:

1. Click on Start, click on All Programs, Click on Administrative Tools and then click on Internet Information Services (IIS) Manager.
2. Highlight the entry on the left-hand pane for your servername (SERVERNAME (DOMAIN\user)).
3. Double-click on WebDAV Authoring Rules.
4. Delete any rules that appear.
5. Highlight your Default Web Site (or ConfigMgr 2007 web site) and edit the WebDAV settings at that level as explained in this article:  http://technet.microsoft.com/en-us/library/cc431377.aspx

For all the details and the latest version of this document please see the following new Knowledge Base article:

KB2378924 -  System Center Configuration Manager 2007 prerequisites checker reports WebDAV settings are incorrect

J.C. Hornbeck | System Center Knowledge Engineer

Symptoms

When modifying Multicast settings in the properties of a Distribution Point, the values for "MultiCast address", "UDP port range", and "Transfer rate" can all be modified under the "Multicast" tab of the ConfigMgr distribution point Properties. After configuring the settings, the settings are modified and applied in the GUI of the "Multicast" tab of the ConfigMgr distribution point Properties.

However, when attempting to Multicast, the Multicast sessions do not work, or do not work based on the values sepcified in the "Multicast" tab of the ConfigMgr distribution point Properties. Performing network traces confirms that the values being seen in the network traces seem to indicate that the Multicast sessions are using the default values originally set in the "MultiCast" tab of the ConfigMgr distribution point Properties, and not the modified values. Reinspecting the values under the the "Multicast" tab of the ConfigMgr distribution point Properties shows that the settings and values in the GUI have been modified and are set to the desired values.

Other values under the "Multicast" tab of the ConfigMgr distribution point Properties window that may have been changed seem to have been applied and work correctly, such as "Specify the account to connect to the database", "Enable scheduled multicast", and "Maximum" clients. Only the "MultiCast address", "UDP port range", and "Transfer rate" settings seem to have issues.

Cause

This problem is caused by a known issue in ConfigMgr 2007 R2 and R3 where the "MultiCast address", "UDP port range", and "Transfer rate" settings  specified under the "Multicast" tab of the ConfigMgr distribution point Properties may not actually set the settings correctly. Specifically, the "MultiCast address", "UDP port range", and "Transfer rate" settings are Windows Server 2008/Windows Server 2008 R2 Windows Deployment Services (WDS) settings. When these settings are configured in the ConfigMgr distribution point Properties, ConfigMgr 2007 will automatically set the WDS settings in the background. However due to the known issue, the settings are actually never set, even though they show correctly under the "Multicast" tab of the ConfigMgr distribution point Properties GUI.

Please note that the "Transfer rate" setting is a Windows Server 2008 WDS only setting. Windows Server 2008 R2 automatically detects the optimal network speeds and sets the transfer rate settings accordingly, so the setting does not apply to Windows Server 2008 R2 WDS. Setting the "Transfer rate" setting on a Multicast Distribution Point running on Windows Server 2008 R2 has no effect.

Resolution

To resolve the problem, the corresponding registry settings for "MultiCast address", "UDP port range", and "Transfer rate" need to be manually set in the registry after they have been set in the "Multicast" tab of the ConfigMgr distribution point Properties GUI window. Since the recommended practice when using ConfigMgr 2007 is to NOT configure WDS manually, the corresponding settings should not be set in the WDS console. Instead the corresponding resgistry settings should be set manually instead.

1. On the server hosting the Distibution Point role where multicast is being enabled, make sure that WDS is installed and that the "Deployment Server" and "Transport Server" role services are installed. Additionally, make sure that WDS has not be manually configured on the server.
2. In the ConfigMgr 2007 Admin console, navigate to "Site Management" --> "Site Settings" --> "Site Systems".
3. Under the "Site Systems" node, click on the applicable server from Step 1 where WDS is installed.
4. On the right hand pane, rigt click on "ConfigMgr distirbution point" and choose "Properties".
5. In the "ConfigMgr distribution point Properties" window, click on the "Multicast" tab.
6. Make sure that the option "Enable Multicast" is checked.
7. Set all of the appropriate settings under the "Multicast" tab as desired for the environment, even if some of them ("MultiCast address", "UDP port range", and "Transfer rate") do not seem to actually apply.
8. Click on the "OK" or "Apply" button to ensure that the settings are saved.
9. On the server from Step 1, open the Registry Editor by starting "regedit.exe".
10. To manually set the "MultiCast address" and "UDP port range" settings, in the Registry Editor navigate to:
    
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Parameters
    
11. Map the appropriate settings from the "Multicast" tab of the ConfigMgr distribution point Properties GUI to the corresponding registry settings listed below, and then manually change the value of the registry setting to match the settings configured in Step 7:
    • To set the option "Use IP address from the following range" under the "MultiCast address" section:
      • "IPv4 From: " field --> McStartAddr
      • "To: " field --> MCEndAddr
        
    • To set the option "Use UDP ports from the following range:" under the "UDP port range" section:
      • "From: " --> UdpStartPort
      • "To:" --> UdpEndPort
        
12. The "Transfer Rate" setting should only be set in Windows Server 2008. It should not be set in Windows Server 2008 R2. To manually set the "Transfer Rate" setting in Windows Server 2008, in the Registry Editor navigate to:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSMC
    Change the value of "DefaultProfile" to the desired setting (10Mbps, 100Mbps, 1Gbps, or Custom).
    If using Custom, make sure to make the necessary customizations under the registry key:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSMC\Profiles\Custom
    Do not make any customizations to any of the built in profiles (10Mbps, 100Mbps, 1Gbps). Use the Custom profile if any customizations are desired.
13. When the registry settings have been changed and set, restart the "Windows Deployment Services Server" service on the server from Step 1 using the Services console found under Adminsitrative Tools.

Note:
Setting the "Transfer rate" setting on a Multicast Distribution Point running on Windows Server 2008 R2 has no effect. The "Transfer rate" setting is actually only a Windows Server 2008 WDS setting. It does not apply to Windows Server 2008 R2 WDS. Windows Server 2008 R2 automatically detects the optimal network speeds and sets the transfer rate settings accordingly.

Inspecting the registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSMC

on a Windows Server 2008 R2 reveals that there is no "DefaultProfile" value. This is normal and the key value should not be created. Please see the following TechNet documentation regarding this setting:

How to Manage Your Server
http://technet.microsoft.com/en-us/library/cc770637(WS.10).aspx#BKMK_1

General Tasks --> To Configure the network profile for the server
"Note that these procedures only apply to the initial release of Windows Server 2008"

IWdsTransportServicePolicy::NetworkProfile Property
http://msdn.microsoft.com/en-us/library/bb736515(VS.85).aspx

"Windows Server 2008 R2:  This property is ignored and has no effect. This property is ignored and has no effect. A WDS Transport Server on Windows Server 2008 R2 automatically uses the optimal network profile."

/set-Server
http://technet.microsoft.com/en-us/library/cc816898(WS.10).aspx

Parameter --> /Transport
[/Profile: {10Mbps | 100Mbps | 1Gbps | Custom}] - Specifies the network profile to be used. This option is only supported for servers running Windows Server 2008

/set-TransportServer
http://technet.microsoft.com/en-us/library/cc794752(WS.10).aspx

Parameter
[/Profile: {10Mbps | 100Mbps | 1Gbps | Custom}]
Specifies the network profile to be used. This option is only available for servers running Windows Server 2008 or Windows Server 2003.

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

KB2419357 - WDS Multicast settings in the Distribution Point properties do not seem to apply in System Center Configuration Manager 2007 R2 and R3

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The OpsMgr Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis

You may notice that an unusually large number of System Center Configuration Manager 2007 status messages are generated causing significant growth in database size.  Further investigation also shows a large number of these entries repeating over and over again in the distmgr.log:

Compressed files for package xxx hasn't arrived from site xxx

Note: These messages can occur on a normally functioning site.  It is only a cause for concern when an excessively large number are repeatedly seen.

This can be caused by the issue documented in the following Knowledge Base articles:

SP1 version:  KB978875 - The Distribution Manager does not honor the "Number of retries" and "Delay before retrying (minutes)" retry settings on SCCM 2007 SP1 site servers

SP2 and later version:  KB978021 - The Distribution Manager that is in System Center Configuration Manager 2007 SP2 does not honor the "Number of retries" and "Delay before retrying (minutes)" retry settings

To resolve this issue apply the appropriate hotfix referenced above.

Troubleshooting and verification:

You can use this script to determine that the status specific tables are largest in the ConfigMgr database:

http://www.sqlteam.com/article/finding-the-biggest-tables-in-a-database

Then you can use these queries to determine the components generating the most status messages.  In this specific scenario you'll find that it is Distribution Manager.

select Component, count(*) from vStatusMessages group by Component order by count(*) desc
select MessageID, count(*) from vStatusMessages group by MessageID order by count(*) desc

ref: http://blogs.technet.com/b/configurationmgr/archive/2009/01/27/troubleshooting-database-growth-issues-in-configuration-manager-2007.aspx

You should find that the SMS_DISTRIBUTION_MANAGER thread has been generating status message ID's 2342, 2300 and 2301 or similar every 5 seconds, repeatedly.

So what's the takeaway from all this? 

If you have System Center Configuration Manager 2007 SP1 or later and are doing software distribution then you need this hotfix!

Clint Koenig | Senior Support Escalation Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The OpsMgr Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis

When pushing a software distribution package with .ASPX or .ASMX files to a Branch Distribution Point (BDP), the transfer fails. Transfers via SMB to the same BDPs work fine. You may also see BITS jobs failing with transient errors.

Cause

This occurs because .ASPX and .ASMX files are dynamic content and BITS will not download dynamic content. This is by design. Since a BDP will only use BITS to get the package from the Distribution Point it fails.

ref: http://msdn.microsoft.com/en-us/library/aa362846(v=VS.85).aspx

Resolution

Other than not including ASPX or ASMX files in your packages, as a workaround you can pre-stage the content on the BDP manually.

1. If one does not already exist, create an SMSPKG<driveletter>$ directory and share on the branch distribution point.

2. Using a standard distribution point as the original source for the package, copy the packages into the SMSPKG<driveletter>$ directory.

3. On the central site where your packages exist, select your package and chose properties. On the Distribution Settings tab make sure that the Administrator manually copies this package to branch distribution points to checked.

4. Next use the package wizard to add a DP to the package. In this case you will be selecting the Branch DP.

5. Give it a few minutes to allow the new policy to flow down from the central site to the Branch DP Clients parent site.

6. Force the client to request new Machine Policy or allow it to request Machine policy on its own. Once policy is received it will take 2 minutes before the policy is applied to this client.

7. On the branch distribution point computer, double-click Configuration Manager in Control Panel.

8. On the Actions tab, select Branch Distribution Point Maintenance Task and then click Initiate Action

*Note: When creating an SMSPKG<driveletter>$ directory and share, the <driveletter> is the relevant drive on the branch distribution point. For example, SMSPKGC$ would be the directory and share created on drive C of the branch distribution point.

More Information

For more information see How to Prestage Packages on a Branch Distribution Point in the TechNet library.

=====

The information above was published today in the following Microsoft Knowledge Base article written by J.C. Hornbeck and Clifton Hughes:

KB2516319 - Packages with .ASPX and .ASMX files cannot be distributed to Configuration Manager 2007 Branch Distribution Points

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis
The Service Manager Team blog: http: http://blogs.technet.com/b/servicemanager
The AVIcode Team blog: http: http://blogs.technet.com/b/avicode
The System Center Essentials Team blog: http: http://blogs.technet.com/b/systemcenteressentials

Hi folks, my name is Yuvaraj Tamil Mani and I’d like to take a minute and share some information about the flow of package distribution to a standard Distribution Point (DP) and a Branch Distribution Point (BDP).

When a package is sent to a standard DP, the Distribution Manager component connects to the SMSPKGdriveletter$ of the DP, copies the package contents, and updates the package status in the database. However, when a package is sent to a branch distribution point, the flow is different and I have tried to explain it in detail with log snippets as you’ll see below.

NOTE The site server logs are SQL enabled; MP and client logs are Verbose and debug enabled.

The following are the details that I used in the examples:

• Package ID : CS10001E
• Site server/MP/DP : CS1SRV.NINJAS.COM
• BDP Name : CS1XP.NINJAS.COM

Flow of sending a package to a standard Distribution Point:

The following are the actions performed when you send a package to a standard DP.

1. When you add a package to a standard Distribution Point, the distmgr component is notified with the packageID.PKN in inboxes\distmgr.box.

2. The distmgr component begins the processing of the package with STATMSG 2300:

STATMSG: ID=2300SEV=I LEV=M SOURCE="SMS Server" COMP="SMS_DISTRIBUTION_MANAGER" SYS=CS1SRV SITE=CS1 PID=4604 TID=5720 GMTDATE=Fri Jan 13 22:36:47.610 2012 ISTR0="Test BDP 2" ISTR1="CS10001E" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=1 AID0=400 AVAL0="CS10001E" SMS_DISTRIBUTION_MANAGER 1/14/2012 4:06:47 AM 5720 (0x1658)

No action specified for the package CS10001E. SMS_DISTRIBUTION_MANAGER 1/14/2012 4:06:47 AM 5720 (0x1658)

Start adding package to server ["Display=\\CS1SRV\"]MSWNET:["SMS_SITE=CS1"]\\CS1SRV\... SMS_DISTRIBUTION_MANAGER 1/14/2012 4:06:47 AM 5720 (0x1658)

["Display=\\CS1SRV\"]MSWNET:["SMS_SITE=CS1"]\\CS1SRV\ is NOT a Branch DP SMS_DISTRIBUTION_MANAGER 1/14/2012 4:06:47 AM 5720 (0x1658)

3. Distmgr establishes a connection to the DP and checks for the SMSPKGdriveletter$ share:

Established connection to ["Display=\\CS1SRV\"]MSWNET:["SMS_SITE=CS1"]\\CS1SRV\ SMS_DISTRIBUTION_MANAGER 1/14/2012 4:06:47 AM 3272 (0x0CC8)

Signature share exists on distribution point path MSWNET:["SMS_SITE=CS1"]\\CS1SRV\SMSSIG$\ SMS_DISTRIBUTION_MANAGER 1/14/2012 4:06:47 AM 3272 (0x0CC8)

The distribution point ["Display=\\CS1SRV\"]MSWNET:["SMS_SITE=CS1"]\\CS1SRV\ doesn't point to an existing path. SMS_DISTRIBUTION_MANAGER 1/14/2012 4:06:47 AM 3272 (0x0CC8)

The best drive on the distribution point is C:\ SMS_DISTRIBUTION_MANAGER 1/14/2012 4:06:47 AM 3272 (0x0CC8)

The best drive for installing package on the distribution point ["Display=\\CS1SRV\"]MSWNET:["SMS_SITE=CS1"]\\CS1SRV\ is C:\ SMS_DISTRIBUTION_MANAGER 1/14/2012 4:06:47 AM 3272 (0x0CC8)

Share SMSPKGC$ exists on distribution point ["Display=\\CS1SRV\"]MSWNET:["SMS_SITE=CS1"]\\CS1SRV\ SMS_DISTRIBUTION_MANAGER 1/14/2012 4:06:47 AM 3272 (0x0CC8)

4. It creates a subdirectory with the package ID in the SMSPKGC$ share:

Attempting to create subdirectory CS10001E under the export. SMS_DISTRIBUTION_MANAGER 1/14/2012 4:06:48 AM 3272 (0x0CC8)

The export is accessible. SMS_DISTRIBUTION_MANAGER 1/14/2012 4:06:48 AM 3272 (0x0CC8)

Successsfully created the package directory CS10001E\ under the export. SMS_DISTRIBUTION_MANAGER 1/14/2012 4:06:48 AM 3272 (0x0CC8)

Successfully created sub directory CS10001E off MSWNET:["SMS_SITE=CS1"]\\CS1SRV\SMSPKGC$\CS10001E\ SMS_DISTRIBUTION_MANAGER 1/14/2012 4:06:48 AM 3272 (0x0CC8)

5. Distmgr connects to the packageID folder it created and checks if the drive has the enough free space to copy the package contents:

Attempting to make an accessible connection to MSWNET:["SMS_SITE=CS1"]\\CS1SRV\SMSPKGC$\CS10001E\, get its NOS path, and get its number of free bytes. SMS_DISTRIBUTION_MANAGER 1/14/2012 4:06:50 AM 3272 (0x0CC8)

Established connection to MSWNET:["SMS_SITE=CS1"]\\CS1SRV\SMSPKGC$\CS10001E\ SMS_DISTRIBUTION_MANAGER 1/14/2012 4:06:50 AM 3272 (0x0CC8)

Getting the number of free bytes. SMS_DISTRIBUTION_MANAGER 1/14/2012 4:06:50 AM 3272 (0x0CC8)

The number of free K bytes 40105592 SMS_DISTRIBUTION_MANAGER 1/14/2012 4:06:50 AM 3272 (0x0CC8)

Successfully made an accessible connection, got a NOS path, and, if requested, got the number of free bytes at this location. SMS_DISTRIBUTION_MANAGER 1/14/2012 4:06:50 AM 3272 (0x0CC8)

6. Distmgr sets the security on the \\ CS1SRV\SMSPKGC$\CS10001Efolder and copies the package contents to that folder from the package source. It also copies the signature file (TAR file) to the SMSSIG$ share and sets the security on that folder:

Successfully set access security on MSWNET:["SMS_SITE=CS1"]\\CS1SRV\SMSPKGC$\CS10001E\ for package CS10001E SMS_DISTRIBUTION_MANAGER 1/14/2012 4:06:50 AM 3272 (0x0CC8)

GetPackageSignature() called for package CS10001E with version 1. UnpackedSignature = 0 SMS_DISTRIBUTION_MANAGER 1/14/2012 4:06:50 AM 3272 (0x0CC8)

Copying C:\package source\Test BDP 2\CcmTools.msi to C:\SMSPKGC$\CS10001E\CcmTools.msi, OK SMS_DISTRIBUTION_MANAGER 1/14/2012 4:06:50 AM 3272 (0x0CC8)

RDC:Successfully copied package signature file C:\SMSPKGSIG\CS10001E.1.tar to \\CS1SRV\SMSSIG$\\CS10001E.1.tar SMS_DISTRIBUTION_MANAGER 1/14/2012 4:06:50 AM 3272 (0x0CC8)

RDC:Successfully set access security on \\CS1SRV\SMSSIG$\\CS10001E.1.tar for package CS10001E signature file SMS_DISTRIBUTION_MANAGER 1/14/2012 4:06:50 AM 3272 (0x0CC8)

Successfully copied package CS10001E from C:\package source\Test BDP 2\ to MSWNET:["SMS_SITE=CS1"]\\CS1SRV\SMSPKGC$\CS10001E\ SMS_DISTRIBUTION_MANAGER 1/14/2012 4:06:50 AM 3272 (0x0CC8)

7. Distmgr runs the following query to update the status in the pkgstatus table in SQL and raises a STATMSG 2330:

SQL>>>update PkgStatus set Status = 3, UpdateTime = "01/14/2012 04:06:50", Location = "MSWNET:[""SMS_SITE=CS1""]\\CS1SRV\SMSPKGC$\CS10001E\", ShareName = "", HTTPUrl = "http://CS1SRV/SMS_DP_SMSPKGC$/CS10001E/", SourceVersion = 1, State = 0, SigURL = "http://CS1SRV/SMS_DP_SMSSIG$/CS10001E.1.tar", SigLocation = "MSWNET:[""SMS_SITE=CS1""]\\CS1SRV\SMSSIG$\CS10001E.1.tar" where ID = "CS10001E" and Type = 2 and Personality = 0 and SiteCode = "CS1" and PkgServer = "[""Display=\\CS1SRV\""]MSWNET:[""SMS_SITE=CS1""]\\CS1SRV\" SMS_DISTRIBUTION_MANAGER 1/14/2012 4:06:50 AM 3272 (0x0CC8)

STATMSG: ID=2330 SEV=I LEV=M SOURCE="SMS Server" COMP="SMS_DISTRIBUTION_MANAGER" SYS=CS1SRV SITE=CS1 PID=4604 TID=3272 GMTDATE=Fri Jan 13 22:36:50.954 2012 ISTR0="CS10001E" ISTR1="["Display=\\CS1SRV\"]MSWNET:["SMS_SITE=CS1"]\\CS1SRV\" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=2 AID0=400 AVAL0="CS10001E" AID1=404 AVAL1="["Display=\\CS1SRV\"]MSWNET:["SMS_SITE=CS1"]\\CS1SRV\" SMS_DISTRIBUTION_MANAGER 1/14/2012 4:06:50 AM 3272 (0x0CC8)

Flow of sending a package to a Branch Distribution point:

The following are the actions performed when you send a package to a Branch Distribution Point:

1. When we add a BDP to a package, the distmgr component checks the DPID in distributionpoints table to determine whether it is a BDP.

SQL>>>select DPID, NALPath from DistributionPoints where NALPath = '["Display=\\CS1XP\"]MSWNET:["SMS_SITE=CS1"]\\CS1XP\' and IsPeerDP = 1 1/14/2012 4:09:57 AM 6748 (0x1A5C)

DPID 11 - NAL Path ["Display=\\CS1XP\"]MSWNET:["SMS_SITE=CS1"]\\CS1XP\ is a Branch DP 1/14/2012 4:09:57 AM 6748 (0x1A5C)

2. Distmgr component inserts an entry into the pkgstatus table with status 0 for the BDP:

SQL>>>insert PkgStatus (ID, Type, SourceVersion, Personality, Location, SiteCode, PkgServer, ShareName, HTTPUrl, Status, State, SigLocation, SigURL, UpdateTime) values ("CS10001E", 2, 1, 0, "", "CS1", "[""Display=\\CS1XP\""]MSWNET:[""SMS_SITE=CS1""]\\CS1XP\", "", "", 0, 2, "", "", "01/14/2012 04:09:57") 1/14/2012 4:09:57 AM 6748 (0x1A5C)

3. Distmgr updates the peerdppkgmap table which has the list of all packages sent to branch distribution points:

SQL>>>insert PeerDPPkgMap (PkgID, DPID) values ('CS10001E', 11) 1/14/2012 4:09:58 AM 6748 (0x1A5C)

SQL>>>>> Done. 1/14/2012 4:09:58 AM 6748 (0x1A5C)

Successfully updated PeerDPPkgMap for DPID 11 and PkgID CS10001E. 1/14/2012 4:09:58 AM 6748 (0x1A5C)

4. Distmgr sends a trigger to policy provider by a file notification in inboxes\policypv folder:

Created policy provider trigger for ID CS10001E 1/14/2012 4:09:58 AM 6748 (0x1A5C)

5. The policy provider creates a policy and policy assignment for the package. It also maps the resources to the policy:

Successfully created policy {133e16b6-e7f4-4a6a-833d-ec64703c884a} and policy assignment {e79d710f-264a-4c1c-86c1-c6c5268a79ef} based on package CS10001E SMS_POLICY_PROVIDER 1/14/2012 4:10:03 AM 3204 (0x0C84)

Successfully updated policy and policy assignment based on package CS10001E SMS_POLICY_PROVIDER 1/14/2012 4:10:04 AM 3204 (0x0C84)

Beginning to update the resource to policy mapping... SMS_POLICY_PROVIDER 1/14/2012 4:10:04 AM 3204 (0x0C84)

Successfully updated the resource to policy mapping for 1 resources SMS_POLICY_PROVIDER 1/14/2012 4:10:09 AM 3204 (0x0C84)

6. When the branch distribution point checks the management point for policy, it receives the policy assignment and downloads the policy:

Total 1 PolicyAssignment(s) found. PolicyAgent_ReplyAssignments 1/15/2012 11:50:23 AM 1536 (0x0600)

Validating PolicyAssignment '{e79d710f-264a-4c1c-86c1-c6c5268a79ef}'. PolicyAgent_ReplyAssignments 1/15/2012 11:50:23 AM 1536 (0x0600)

Compiling policy '{133e16b6-e7f4-4a6a-833d-ec64703c884a}' version '1.00' from 'SMS:CS1' (2012-01-14 04:10:09.463) PolicyAgent_ReplyAssignments 1/15/2012 11:50:24 AM 1536 (0x0600)

Starting download of policy 'CCM_Policy_Policy4.PolicyID="{133e16b6-e7f4-4a6a-833d-ec64703c884a}",PolicySource="SMS:CS1",PolicyVersion="1.00"' from 'http://CS1SRV.NINJAS.COM/SMS_MP/.sms_pol?{133e16b6-e7f4-4a6a-833d-ec64703c884a}.1_00' PolicyAgent_ReplyAssignments 1/15/2012 11:50:24 AM 1536 (0x0600)

Download of policy 'CCM_Policy_Policy4.PolicyID="{133e16b6-e7f4-4a6a-833d-ec64703c884a}",PolicySource="SMS:CS1",PolicyVersion="1.00"' started (DTS job ID: '{5C352D39-D872-45B8-85B5-6401074D6ED1}') PolicyAgent_ReplyAssignments 1/15/2012 11:50:24 AM 1536 (0x0600)

Successfully initiated download of policy 'CCM_Policy_Policy4.PolicyID="{133e16b6-e7f4-4a6a-833d-ec64703c884a}",PolicySource="SMS:CS1",PolicyVersion="1.00"' PolicyAgent_ReplyAssignments 1/15/2012 11:50:24 AM 1536 (0x0600)

Starting download of policy 'CCM_Policy_Policy4.PolicyID="{133e16b6-e7f4-4a6a-833d-ec64703c884a}",PolicySource="SMS:CS1",PolicyVersion="1.00"' from 'http://CS1SRV.NINJAS.COM/SMS_MP/.sms_pol?{133e16b6-e7f4-4a6a-833d-ec64703c884a}.1_00' PolicyAgent_ReplyAssignments 1/15/2012 11:50:24 AM 1536 (0x0600)

Download of policy CCM_Policy_Policy4.PolicyID="{133e16b6-e7f4-4a6a-833d-ec64703c884a}",PolicySource="SMS:CS1",PolicyVersion="1.00" completed (DTS Job ID: {5C352D39-D872-45B8-85B5-6401074D6ED1}) PolicyAgent_PolicyDownload 1/15/2012 11:50:27 AM 2536 (0x09E8)

The policy assignment ID and policy ID in the policyagent.log matches with the ID’s in the policypv.log.

7. Now the peerdpagent creates a job for the package CS10001E for downloading and processing the package content:

PDP_CreateJobData PeerDPAgent 1/15/2012 11:50:27 AM 3232 (0x0CA0)

Created Branch DP job {36676F89-F7EB-4055-9AF5-269FBAC38D58} for package CS10001E PeerDPAgent 1/15/2012 11:50:28 AM 3232 (0x0CA0)

NOTE Each package targeted to the BDP has a job in the following location on WMI:  CCM_PeerDP_Job class under root\ccm\peerdpagent

8. The PeerDPagent checks whether the content for the package is prestaged:

CPDPJob::CheckForPreStagedPkg PeerDPAgent 1/15/2012 11:50:28 AM 2536 (0x09E8)

Checking C:\SMSPKGC$\CS10001E for prestaged CS10001E package PeerDPAgent 1/15/2012 11:50:28 AM 2536 (0x09E8)

Package CS10001E has not been prestaged PeerDPAgent 1/15/2012 11:50:28 AM 2536 (0x09E8)

9. Peerdpagent checks for the BDPTmpWrkFldr directory and creates a temp folder inside it for download:

Directory 'C:\BDPTmpWrkFldr\' already exists. PeerDPAgent 1/15/2012 11:50:28 AM 2536 (0x09E8)

Temp dowload Path: 'C:\BDPTmpWrkFldr\PDP119.tmp' PeerDPAgent 1/15/2012 11:50:28 AM 2536 (0x09E8)

Disconnected 0 users from directory C:\BDPTmpWrkFldr\PDP119.tmp. PeerDPAgent 1/15/2012 11:50:28 AM 2536 (0x09E8)

10. Peerdpagent calls the content transfer manager to start the download:

Calling DownloadContent, the type is 0, priority 2 PeerDPAgent 1/15/2012 11:50:28 AM 2536 (0x09E8)

Raising event:

[SMS_CodePage(437), SMS_LocaleID(1033)]

instance of PDPDownloadStartedEvent

{

ClientID = "GUID:9B783DCB-5511-4C76-864D-01E57731172E";

DateTime = "20120115062028.451000+000";

MachineName = "CS1XP";

PackageID = "CS10001E";

ProcessID = 1920;

SiteCode = "CS1";

SourceVersion = 1;

ThreadID = 2536;

};

PeerDPAgent 1/15/2012 11:50:28 AM 2536 (0x09E8)

11. The content transfer manager completes the download and notifies the peerdpagent:

CTM job {D8718FED-D7A6-439F-8F3E-4B1389B590C8} successfully processed download completion. ContentTransferManager 1/15/2012 11:50:32 AM 1536 (0x0600)

CCTMJob::EvaluateState(JobID={D8718FED-D7A6-439F-8F3E-4B1389B590C8}, State=Success) ContentTransferManager 1/15/2012 11:50:32 AM 2604 (0x0A2C)

CCTMJob::EvaluateState(JobID={D8718FED-D7A6-439F-8F3E-4B1389B590C8}, State=Complete) ContentTransferManager 1/15/2012 11:50:32 AM 2604 (0x0A2C)

12. We can find the notification from CTM in the Peerdpagent.log:

CPDPJob::ProcessProgress PeerDPAgent 1/15/2012 11:50:28 AM 2536 (0x09E8)

Download complete for CTM job {D8718FED-D7A6-439F-8F3E-4B1389B590C8}, downloaded KB 1058 PeerDPAgent 1/15/2012 11:50:32 AM 2536 (0x09E8)

Package CS10001E in state 'DownloadComplete'. PeerDPAgent 1/15/2012 11:50:32 AM 2536 (0x09E8)

instance of PDPDownloadSuccessEvent

{

ClientID = "GUID:9B783DCB-5511-4C76-864D-01E57731172E";

DateTime = "20120115062032.654000+000";

MachineName = "CS1XP";

PackageID = "CS10001E";

ProcessID = 1920;

SiteCode = "CS1";

SourceVersion = 1;

ThreadID = 2536;

};

13. Peerdpagent checks the hash for the package and verifies it with the hash that it got through policy from the MP:

Package CS10001E in state 'HashContentSuccess'. PeerDPAgent 1/15/2012 11:50:32 AM 2536 (0x09E8)

Hash verified for package CS10001E. PeerDPAgent 1/15/2012 11:50:32 AM 2536 (0x09E8)

14. It creates a folder under SMSPKGdriveletter$ with the package ID and copies the content from the temp directory to the PackageID folder and completes the provisioning:

Directory 'C:\SMSPKGC$' already exists. PeerDPAgent 1/15/2012 11:50:32 AM 2536 (0x09E8)

Disconnected 0 users from directory C:\BDPTmpWrkFldr\PDP119.tmp. PeerDPAgent 1/15/2012 11:50:32 AM 2536 (0x09E8)

Package CS10001E in state 'HostingComplete'. PeerDPAgent 1/15/2012 11:50:32 AM 2536 (0x09E8)

Package CS10001E provisioned at C:\SMSPKGC$\CS10001E PeerDPAgent 1/15/2012 11:50:32 AM 2536 (0x09E8)

instance of PDPProvisionSuccessEvent

{

ClientID = "GUID:9B783DCB-5511-4C76-864D-01E57731172E";

DateTime = "20120115062032.998000+000";

MachineName = "CS1XP";

PackageID = "CS10001E";

ProcessID = 1920;

Share = "C:\\SMSPKGC$\\CS10001E";

SiteCode = "CS1";

SourceVersion = 1;

ThreadID = 2604;

};

15. Peerdpagent raises a status 3 (Installed) and you can see the message in peerdpagent.log:

StatusFile message body for package 6271482 :

<PeerDPDownloadStatus><ClientID>GUID:9B783DCB-5511-4C76-864D-01E57731172E</ClientID><Msg PkgID="CS10001E" Location="MSWNET:[&quot;SMS_SITE=CS1&quot;]\\CS1XP\SMSPKGC$\CS10001E\" SiteCode="CS1" Type="2" SourceVersion="1" Personality="0" Status="3" State="3" UpdateTime="1326608432" PackageServer="[&quot;Display=\\CS1XP\&quot;]MSWNET:[&quot;SMS_SITE=CS1&quot;]\\CS1XP\" ShareName="SMSPKG" HttpUrl=""/></PeerDPDownloadStatus> PeerDPAgent 1/15/2012 11:50:32 AM 2604 (0x0A2C)

16. The above status message is sent to the MP_Relayendpoint by ccmexec component:

OutgoingMessage(Queue='mp_mp_relayendpoint', ID={5C3FFB3D-A554-4E4D-AE80-FA65960F2B7F}): Delivered successfully to host 'CS1SRV.NINJAS.COM'. CcmExec 1/15/2012 11:50:33 AM 1536 (0x0600) 

17. The MP_relay.log shows that it received the exact status message(point 15) sent by ccmexec(point 16):

Message Body :

<PeerDPDownloadStatus><ClientID>GUID:9B783DCB-5511-4C76-864D-01E57731172E</ClientID><Msg PkgID="CS10001E" Location="MSWNET:[&quot;SMS_SITE=CS1&quot;]\\CS1XP\SMSPKGC$\CS10001E\" SiteCode="CS1" Type="2" SourceVersion="1" Personality="0" Status="3" State="3" UpdateTime="1326608432" PackageServer="[&quot;Display=\\CS1XP\&quot;]MSWNET:[&quot;SMS_SITE=CS1&quot;]\\CS1XP\" ShareName="SMSPKG" HttpUrl=""/></PeerDPDownloadStatus> MP_RelayEndpoint 1/15/2012 11:50:33 AM 1980 (0x07BC)

18. The MP_relay notifies the distmgr component by dropping a STA file in the inboxes\distmgr.box\INCOMING folder:

Inv-Relay Task: Processing message body MP_RelayEndpoint 1/15/2012 11:50:33 AM 1980 (0x07BC)

Relay: FileType= STA MP_RelayEndpoint 1/15/2012 11:50:33 AM 1980 (0x07BC)

Relay: Outbox dir: C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\distmgr.box\incoming MP_RelayEndpoint 1/15/2012 11:50:33 AM 1980 (0x07BC)

19. The distmgr component wakes up and updates the pkgstatus table with status 3 (Installed) and deletes the STA file:

Processing incoming file C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\distmgr.box\INCOMING\692QVRQ1.STA. SMS_DISTRIBUTION_MANAGER 1/15/2012 11:50:38 AM 4744 (0x1288)

SQL>>>update PkgStatus set Status = 3, UpdateTime = "01/15/2012 11:50:32", Location = "MSWNET:[""SMS_SITE=CS1""]\\CS1XP\SMSPKGC$\CS10001E\", ShareName = "SMSPKG", HTTPUrl = "", SourceVersion = 1, State = 3, SigURL = "", SigLocation = "" where ID = "CS10001E" and Type = 2 and Personality = 0 and SiteCode = "CS1" and PkgServer = "[""Display=\\CS1XP\""]MSWNET:[""SMS_SITE=CS1""]\\CS1XP\" SMS_DISTRIBUTION_MANAGER 1/15/2012 11:50:38 AM 4744 (0x1288)

Successfully update the package status SMS_DISTRIBUTION_MANAGER 1/15/2012 11:50:38 AM 4744 (0x1288)

Successfully delete package status file C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\distmgr.box\INCOMING\692QVRQ1.STA SMS_DISTRIBUTION_MANAGER 1/15/2012 11:50:38 AM 4744 (0x1288)

20. The following 3 status messages from peerdpagent are uploaded to the MP_Statusreceiver by ccmexec. These 3 events are present in the peerdpagent.log:

PDPDownloadStartedEvent

PDPDownloadSuccessEvent

PDPProvisionSuccessEvent

OutgoingMessage(Queue='mp_statusreceiver', ID={794CCBEB-50F8-4FBC-967F-1729CB816965}): Delivered successfully to host 'CS1SRV.NINJAS.COM'. CcmExec 1/15/2012 11:50:33 AM 2604 (0x0A2C)

21. MP_statusreceiver receives the status and puts the .SVF files into the inboxes\statmgr.box\statmsgs folder:

Mp Status: processing event done. MP_StatusManager 1/15/2012 11:50:28 AM 1980 (0x07BC)

MP Status: SVF file written successfully to "C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\statmgr.box\statmsgs\YMUE4GZ2.SVF" MP_StatusManager 1/15/2012 11:50:28 AM 1980 (0x07BC)

MP Status: SVF file written successfully to "C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\statmgr.box\statmsgs\K5XATWID.SVF" MP_StatusManager 1/15/2012 11:50:32 AM 1980 (0x07BC)

MP Status: SVF file written successfully to "C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\statmgr.box\statmsgs\42FKA9TO.SVF" MP_StatusManager 1/15/2012 11:50:33 AM 1980 (0x07BC)

Mp StatusForwarder done, hr=0 MP_StatusManager 1/15/2012 11:50:33 AM 1980 (0x07BC)

22. The Statmgr component reads the .SVF files, deletes the files and inserts the status into the database by running the 3 following stored procedures:

sp_InsStatusMessage

sp_InsStatusMessageInsStr

sp_InsStatusMessageAttribute

Read 1 status messages from file "C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\statmgr.box\statmsgs\YMUE4GZ2.SVF". SMS_STATUS_MANAGER 1/15/2012 11:50:28 AM 2080 (0x0820)

Deleted file "C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\statmgr.box\statmsgs\YMUE4GZ2.SVF". SMS_STATUS_MANAGER 1/15/2012 11:50:28 AM 2080 (0x0820)

Read 1 status messages from file "C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\statmgr.box\statmsgs\K5XATWID.SVF". SMS_STATUS_MANAGER 1/15/2012 11:50:32 AM 2080 (0x0820)

Deleted file "C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\statmgr.box\statmsgs\K5XATWID.SVF". SMS_STATUS_MANAGER 1/15/2012 11:50:32 AM 2080 (0x0820)

Read 1 status messages from file "C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\statmgr.box\statmsgs\42FKA9TO.SVF". SMS_STATUS_MANAGER 1/15/2012 11:50:33 AM 2080 (0x0820)

Deleted file "C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\statmgr.box\statmsgs\42FKA9TO.SVF". SMS_STATUS_MANAGER 1/15/2012 11:50:33 AM 2080 (0x0820)

Beginning a 938-byte SQL transaction to insert 3 status messages and their 7 insertion strings and 6 attribute ID/value pairs into the database. SMS_STATUS_MANAGER 1/15/2012 11:50:38 AM 2080 (0x0820)

SQL>>>exec sp_InsStatusMessage 3,242142,'SMS Client',1073753174,0,'01/15/2012 06:20:28.451','CS1','','CS1XP','Peer DP Agent',1920,2536,258,30,242143,'SMS Client',1073753175,0,'01/15/2012 06:20:32.654','CS1','','CS1XP','Peer DP Agent',1920,2536,258,30,242144,'SMS Client',1073753193,0,'01/15/2012 06:20:32.998','CS1','','CS1XP','Peer DP Agent',1920,2604,258,30 SMS_STATUS_MANAGER 1/15/2012 11:50:38 AM 2080 (0x0820)

SQL>>>>> Done. SMS_STATUS_MANAGER 1/15/2012 11:50:38 AM 2080 (0x0820)

SQL>>>exec sp_InsStatusMessageInsStr 7,242142,0,'CS10001E',242142,1,'1',242143,0,'CS10001E',242143,1,'1',242144,0,'CS10001E',242144,1,'1',242144,2,'C:\SMSPKGC$\CS10001E' SMS_STATUS_MANAGER 1/15/2012 11:50:38 AM 2080 (0x0820)

SQL>>>>> Done. SMS_STATUS_MANAGER 1/15/2012 11:50:38 AM 2080 (0x0820)

SQL>>>exec sp_InsStatusMessageAttribute 6,242142,408,'GUID:9B783DCB-5511-4C76-864D-01E57731172E','01/15/2012 06:20:28.451',242142,400,'CS10001E','01/15/2012 06:20:28.451',242143,408,'GUID:9B783DCB-5511-4C76-864D-01E57731172E','01/15/2012 06:20:32.654',242143,400,'CS10001E','01/15/2012 06:20:32.654',242144,408,'GUID:9B783DCB-5511-4C76-864D-01E57731172E','01/15/2012 06:20:32.998',242144,400,'CS10001E','01/15/2012 06:20:32.998' SMS_STATUS_MANAGER 1/15/2012 11:50:38 AM 2080 (0x0820)

SQL>>>>> Done. SMS_STATUS_MANAGER 1/15/2012 11:50:38 AM 2080 (0x0820)

Committed the transaction for asynchronous execution. We will poll every 250 milliseconds to determine the success or failure of the transaction. SMS_STATUS_MANAGER 1/15/2012 11:50:38 AM 2080 (0x0820)

22. You can see the above 3 status messages when you select Show messagesàAll on the package status node of the branch distribution point.

Yuvaraj Tamil Mani

Get the latest System Center news onFacebookandTwitter:

App-V Team blog: http://blogs.technet.com/appv/
AVIcode Team blog: http://blogs.technet.com/b/avicode
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
OOB Support Team blog: http://blogs.technet.com/oob/
Opalis Team blog: http://blogs.technet.com/opalis
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
OpsMgr Support Team blog: http://blogs.technet.com/operationsmgr/
SCMDM Support Team blog: http://blogs.technet.com/mdm/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Microsoft’s own Eric Orman just posted a great article over on the Server and Cloud Platform blog.  In the article, Eric talks about upgrading to System Center 2012 Configuration Manager and the Migration Distribution Point upgrade job:

My favorite migration feature within System Center 2012 Configuration Manager is Migration Distribution Point upgrade, which is the ability to perform an in-place upgrade of an existing Configuration Manager 2007 Distribution Point to a Configuration Manager 2012 Distribution Point, while also preserving migrated content and converting it into the new content library. The entire end-to-end process is orchestrated by creating a Migration Distribution Point upgrade job….

You can read the rest of Eric’s article here.

J.C. Hornbeck| System Center & Security Knowledge Engineer

Get the latest System Center news onFacebookandTwitter:

App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Here’s a new Knowledge Base article we published this morning. This one describes a potentially confusing status message you may see when upgrading a Distribution Point in System Center 2012 Configuration Manager.

=====

Symptoms

You try to upgrade a shared Distribution Point to a Microsoft System Center 2012 Configuration Manager Distribution Point. If the upgrade of the Distribution Point fails, the status on the Shared Distribution Points tab is displayed as follows:

Failed to upgrade distribution point.

You might expect the status on the Shared Distribution Points tab to be displayed as follows:

Failed to convert content.

Status

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.

More Information

You can use the Configuration Manager console to upgrade Configuration Manager 2007 Distribution Points that you have shared with System Center 2012 Configuration Manager.

When you upgrade a shared Distribution Point, the Distribution Point is uninstalled from the Configuration Manager 2007 site. Then, the Distribution Point is installed as a System Center 2012 Configuration Manager Distribution Point that is attached to a primary or secondary site that you specify.

The upgrade process copies the migrated content that is stored on the Distribution Point and converts this copy to the System Center 2012 Configuration Manager single instance content store.

=====

For the most current version of this article please see the following:

2691560 - The status of a failed upgrade to a shared Distribution Point may be displayed incorrectly as "Failed to upgrade distribution point" in System Center 2012 Configuration Manager

J.C. Hornbeck| System Center & Security Knowledge Engineer

Get the latest System Center news onFacebookandTwitter:

App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Here’s a new Knowledge Base article we published. This one describes an issue where a PXE enabled Distribution Point will generate a large number of files under C:\ProgramData\Microsoft\Crypto\RSA\S-1-5-18 for each PXE request that it services on the network.

=====

Symptoms

A PXE enabled Distribution Point will generate a number of files under C:\ProgramData\Microsoft\Crypto\RSA\S-1-5-18 for each PXE request that it services on the network. This occurs whether the device sending the PXE request has a Task Sequence deployed to it or not. The generation of files will continue and may consume available hard disk space.

Cause

This occurs whenever a self-signed certificate is used for the Distribution Point (DP).

Resolution

To work around this problem, request a CA issued certificate for the PXE enabled DP and specify the PFX file under the properties of the DP. Step-by-step instructions on how to do create the PFX file are available in the Deploying the Client Certificate for Distribution Points section of http://technet.microsoft.com/en-ca/library/230dfec0-bddb-4429-a5db-30020e881f1e#BKMK_clientdistributionpoint2008_cm2012.

More Information

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.

=====

For the most current version of this article please see the following:

2713467 - A PXE enabled Distribution Point that uses a self-signed certificate will generate many files in System Center 2012 Configuration Manager

J.C. Hornbeck| System Center & Security Knowledge Engineer

Get the latest System Center news onFacebookandTwitter:

App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

When the Configuration Manager client is installed on, or uninstalled from, a server that’s running a multicast distribution point (DP), the IUSR account permission is removed from CCM/SMS_CCM folder. This causes multicast to stop working. Additionally, you may receive the following error message:

Call to HttpSendRequestSync failed for port 80 with status code 401, text: Unauthorized” in mcsmgr.log

Note that this issue affects Configuration Manager 2012, Configuration Manager 2012 R2 and Configuration Manager Current Branch. For complete details please see the following:

3205795 – No IUSR account access after you install the Configuration Manager client on a server that’s running a multicast DP (https://support.microsoft.com/en-us/kb/3205795)

J.C. Hornbeck, Solution Asset PM
Microsoft Enterprise Cloud Group

ConfigMgr 2012 R2

When you try to create a configuration item for a mobile device in Microsoft System Center Configuration Manager current branch, you may encounter a System.InvalidOperationException error. This issue can occur if the user who is assigned a custom security role does not have the proper permissions for the Custom Configuration Setting role.

We published a new KB article that discusses this issue and you can get all the details as well as a resolution here:

3205796 – “System.InvalidOperationException” error when you create a configuration item for a mobile device (https://support.microsoft.com/en-us/kb/3205796)

J.C. Hornbeck, Solution Asset PM
Microsoft Enterprise Cloud Group

A new update is available for the Asset Intelligence (AI) authentication certificate in Microsoft System Center Configuration Manager 2007 Service Pack 2, System Center 2012 Configuration Manager Service Pack 2, System Center 2012 R2 Configuration Manager Service Pack 1, and the current branch of System Center Configuration Manager versions 1606 and earlier. Note that System Center Configuration Manager current branch version 1610 and later versions are pre-provisioned with this version of the Asset Intelligence (AI) authentication certificate so you do not have to apply this update to those versions.

For all the details please see the following:

3207852 – Update for authentication certificate in System Center Configuration Manager Asset Intelligence is available (https://support.microsoft.com/en-us/kb/3207852)

J.C. Hornbeck, Solution Asset PM
Microsoft Enterprise Cloud Group

ConfigMgr 2007 SP2 ConfigMgr 2012 R2 SP2 ConfigMgr 1511 ConfigMgr 1602 ConfigMgr CB

As you’re probably already aware, in October we announced a new simplified servicing model, where on the 2ndTuesday of each month you will see a new Security Monthly Quality Rollup as well as a new Security Only Quality Update. Because the Security Monthly Quality Rollup contains the same security fixes as the Security Only Quality Update, as well as all fixes from previous monthly rollups and Security Only Quality Updates, there is a supersedence relationship between these updates, and this relationship was described in this post.

However, please note that for December, the Monthly Rollup will not supersede the Security Only update of the same month, nor will it supersede the Security Only update of previous months. Customers using Configuration Manager 2007 will see both updates available to them for deployment (as seen in October), and can deploy the update of their choice using the Software Update Management functionality. In the absence of supersedence, the December Security Only update has installation applicability logic to not install if the Monthly Rollup is installed. This alleviates the impact Monthly Rollup customers observed in October, when the Security Only update would still be installable and show as missing or required in certain compliance tools. Now, customers of the December Monthly Rollup will not see the December Security Only update as missing or required.

Also, with the release of the December updates on Patch Tuesday (12/13), we also revised the following updates:

• The November Security Only Quality Update
• The November Security Monthly Quality Rollup
• The October Security Only Quality Update.

These updates have been rereleased to leverage the same new logic as in the December updates, without supersedence between the Monthly Rollups and the Security Only updates. With this rerelease, customers who have yet to deploy an earlier Security Only update will gain the benefit of it not being superseded.  Additionally, customers of the Monthly Rollups will continue to benefit from the Security Only updates not being installable or flagged as missing.

J.C. Hornbeck, Solution Asset PM
Microsoft Enterprise Cloud Group

Administrators who opted in to the early wave deployment for System Center Configuration Manager current branch, version 1610, have an update available in the Updates and Servicing node of the Configuration Manager console. This update, made available on December 12, 2016, addresses important late-breaking issues that were discovered during the final release process for version 1610. This update does not apply to sites that update or install a copy of version 1610 that was downloaded before December 1, 2016.

For more information, including the issues fixed, please see the following:

3211925 – Update 2 for System Center Configuration Manager version 1610, early wave (https://support.microsoft.com/en-us/kb/3211925)

J.C. Hornbeck, Solution Asset PM
Microsoft Enterprise Cloud Group

ConfigMgr 1610

Consider the following scenario:

• You’re running Configuration Manager current branch, version 1511 through 1606, or version 1610 LTSB.
• Your old primary site was being used for client piloting.
• You perform site expansion.

In this scenario, the Configuration Manager Client Piloting Package fails. When this occurs, you receive a status message stating that Distribution Manager failed to access the source directory for Configuration Manager Client Piloting Package content. Additionally, the Distmgr.log file contains errors indicating that Distribution Manager cannot locate the source for PilotUpgrade and cannot process the snapshot of the package.

We have a new KB article that describes this issue as well as how to work around it. For more information please see the following:

3205797 – Client piloting package fails after site expansion in Configuration Manager (https://support.microsoft.com/en-us/kb/3205797)

J.C. Hornbeck, Solution Asset PM
Microsoft Enterprise Cloud Group

We are happy to announce that that update 1612 for the Technical Preview Branch of Microsoft System Center Configuration Manager has been released. Technical Preview Branch releases give you an opportunity to try out new Configuration Manager features in a test environment before they are made generally available. For information on this month’s new preview features, please see the following:

Update 1612 for Configuration Manager Technical Preview Branch – Available Now!

J.C. Hornbeck, Solution Asset PM
Microsoft Enterprise Cloud Group

Version 1610 of System Center Configuration Manager Current Branch (ConfigMgr 1610) contains many changes that are intended to prevent issues and improve features. A list of these changes and fixes is available in the KB article below, Keep in mind that this list is not comprehensive, however it does include the items that the product development team believes are the most relevant to most customers. Many of these changes are in response to customer feedback about product issues and ideas for product improvement. For more information regarding what’s been fixed and/or updated, please see the following:

3213269 – Summary of changes in System Center Configuration Manager current branch, version 1610 (https://support.microsoft.com/en-us/kb/3213269)

Please note that version 1610 is available as an in-console update to be installed at the top-most site in a hierarchy. For more information on installing the 1610 update, see Checklist for installing update 1610 for System Center Configuration Manager.

J.C. Hornbeck, Solution Asset PM
Microsoft Enterprise Cloud Group