Hi there,

A customer I am working with recently implemented a new child primary site and all seemed to be ticking along smoothly until a rather angry DBA turned up to ask why disk space was being consumed at the rate of knots on the SQL server hosting the SCCM databases…First things first, I was impressed with the speed that the DBA noticed this as the database hadn’t actually grown that ‘large’, and as SCCM admins we generally keep an eye on database/backup sizes. 1-0 to the SQL DBA

Now in my experience a fast growing SCCM database generally indicates one of two things; inbox issues or more commonly – site replication issues. Given this was the first child site to be introduced in the hierarchy therefore introducing the first ‘replication’ of content then this seemed like a good avenue to start investigating.

So first things first. Let’s check the database sizes out ourselves (not that we don’t trust the DBA!). We logged on to the SQL server and reviewed the SQL ‘data’ location where we found the SCCM parent site database had ballooned by approx 20% and the new child site database was nearly the same size as the parent site which is strange given it has approx. 90% less client data!

Now that we know that an issue exists we need to identify exactly what tables contain all this ‘extra data’. To do that we need to fire up SQL Management Studio, and log on to the instance as a user with permissions to run a few queries…

First we ran the following query on  both databases to identify large tables;

http://www.sqlteam.com/downloads/BigTables.sql (please note this query is from a third party and has not been tested and as such this is run at your own risk!)

This demonstrated that on the parent site the following tables were consuming more space than expected;

• StatusMessageinsstrs
• StatusMessages
• StatusMessageAttributes

And on the new child primary site;

• TS_TaskSequences

This was the interesting table – it was approx 90% the total size of the database and only had 45 rows! The same table on the parent site was approx 2mb and had 52 rows. You can check the size directly in SQL Management Studio if you wish.

So first things first – the status messages. Let’s review the component status view in the SCCM console. From here we got a bit more information – the SMS_DISTRIBUTION_MANAGER component was flagging thousands of notifications. Viewing this component demonstrated that there were several task sequences repeatedly processing every 5 seconds. Ah! Well first things first we have a patch that should be applied to address issues with distribution points repeatadly processing content/packages/task sequences… and this is KB978021. So let’s install that (on any and all DPs) to suppress these status messages.

Now we need a solution to get rid of some of the status messages in the database of the parent site. It is bad practice to interact with the database directly and for obvious reasons is not supported by Microsoft so therefore we need to look at another way. Another blog post came up with the following solution;

• Fire up WBEMTEST
• Namespace: rootsmssite_<code>
• Execute Method
• Path: sms_statusmessage
• Select ‘Detect By Query’
• Edit In Parameters
• Select WQLSelect
• Select ‘NOT NULL’
• Query:
  • Select * from sms_statusmessage where messageid=’number’ and component = ‘SMS_DISTRIBUTION_MANAGER’

This will remove the status messages and can take some time. If there are lots of these to do then you should consider doing this in chunks. (Again, please try this in a test environment first to ensure no adverse affects occur in your production environment) It is worth noting that status messages are cleared up automatically by one of the SCCM site maintenance tasks… by default audit/component status messages are kept for 180 days, and this is configured in the status message filter section of the site settings.

We should now see the size of the parent site database has decreased. Half way there! Whilst we have stopped the status messages being generated we haven’t fixed the underlying issue. Why were these task sequences constantly processing? For that my next avenue was to look in the DISTMGR log file on the child site. Lo and behold I was greeted with the following messages;

“Failed to insert SMS Package <Packge_ID> because SDM Type Content <Unique_ContentID> is not present in the CI_Contents table. Will try later.”

These messages were repeated constantly, and there was 3 different Package ID’s referenced.

Now whilst these messages lead me to the solution it was a bit confusing as the CI_Contents table pertains to Software Updates. Now this site has a replica WSUS and did at one stage host a SUP however this was removed previously as it was added incorrectly. Whether this caused the issue we were seeing is unknown and was not investigated further.

I took the package ID and compared it to the ‘references’ tab on the task sequences that were not replicating and all the task sequences contained these packages which turned out to be Driver Packages. To resolve the issue  I simply re-created the driver package and modified the task sequences to point to the new version. Very simple, and it worked (after restarting the SMS_DISTRIBUTION_MANAGER component)… the messages disappeared from the DISTMGR log.

So we are nearly there, however one final thing we need to do is reclaim that database space to make the DBA happy. There are a number of SQL commands that can be used, however it is important to note that editing the database is not supported unless instructed to do so by Microsoft Premier Support. Doing so can leave you in an unsupported state. The commands are listed here for reference for you to use in your test environments;

• dbcc cleantable (SMS_CEN, TS_TaskSequence)
• dbcc shrinkdatabase (SMS_CEN)

Where SMS_CEN is the name of your database…
It is worth noting that these take a long time to run, approximately 1 hour per 10gb.

Thanks,
SteveH

We can finally talk/blog about it…. System Center 2012 release just announced at MMS 2012 RTM code is on your VLS! Get downloading!

Hi There,

There are a number of underlying permissions that must be granted in order for a user to be able to successfully initiate a console session to an SCCM environment.

Firstly you need to make sure the user has the correct site permissions… for example, a user requiring Remote Control access may have the following user rights;

• Collection
  • Read, Use Remote Tools, Read Resource

• Site
  • Read

Secondly this user must reside in the relevant site servers Local Group – ‘SMS Admins’. SMS Admins is generally nested in another Local Group – ‘Distributed COM Users’, and you need to check this is the case as well.

Finally, and this was the first time I’ve had to do this for a permission related issue – (and I’ve not discovered the reason why this bit of configuration had been changed or deleted) – you need to make sure that SMS Admins OR the user group containing the Remote Control users has permissions over WMI. To do this you can perform the following;

• Navigate to Server Manager
• Expand Configuration
• Select ‘Properties’ of the WMI Control Object
• Select the Security Tab
• Expand Root
• Select the SMS Folder, and choose Security

• • SMS Admins (or the group containing your users) should have the following permissions;
    • Enable Account
    • Remote Enable

• Select the site_<SiteCode> folder under SMS, and choose Security
  • SMS Admins (or the group containing your users) should have the following permissions;
    • Execute Methods
    • Provider Write
    • Enable Account
    • Remote Enable

That should be enough for your console connectivity to return

Thanks,
SteveH

Hi there,

I came across an issue recently with a child primary site that had failed to replicate a number of resources from it’s parent site.

After working through some of these issues, and rectifying the replication I needed to perform a full child resync.

This is simple to do by running the following command;

• Preinst.exe /CHILDSYNC <SiteCode>   ~ from the parent site

However an error was returned straight away stating that;

• Cannot connect to SQL Database
• <SiteCode> is not a known site

It turned out that this was because the account that I was using to run this did not have Site Modify permissions on the Parent Site. These permissions also need to be assigned directly to the account (not via a Security Group)

Once this was done, I re-run the command and a resync occurred.

Thanks,
Steve

Recently I had the need to do a quick and dirty fix of a couple of virtual applications that had been deployed to users in an environment that uses App-V with SCCM integration. Applications are advertised to users based upon AD Security Group membership and are configured to download and execute, rather than stream from a DP.

Without going into the reasons behind why this can happen (that’s another post) – I’ll demonstrate how to quickly resolve the error and get the user back up and running. Before proceeding make sure you have got SCCM Client Center

A error of this kind would be seen by the user when attempting to launch the broken application, e.g. ;

1. Find the package ID of the affected virtual application
2. Connect to the users SCCM cache (%windir%system32CCMcache) and see if the source files for the affected application are still there (use the package ID to find the folder)
3. If the cached package is still there, load SCCM client center, navigate to Agent Actions > Cache and delete the package from here (this will ensure it is not orphaned)
4. From within Client Center > Client Actions run a Download & Apply User (or machine) policy
5. On the affected machine, restart the SMS Agent Host Service (or reboot)
6. From within Client Center > Advertisements, re-run the advertisement for the failed virtual application

You should now see the application begin to download into the SCCM cache, and once complete the package should register itself with the App-V client and once again be functional.

If this fails your App-V cache may be corrupt. To resolve this you can use SFTMIME which is a tool contained within the App-V client installation directory. The following command can be used to clear all applications from within the cache;

• sftmime.exe remove obj:app /global /complete

Please note, this command will remove all applications from the App-V client, and the user running the command must have administrative permissions.

A full reference for SFTMIME can be found here;

http://technet.microsoft.com/en-us/library/cc817090.aspx

Thanks,
SteveH

Hi There,

During testing of a SHIM to fix an application, I accidentally deleted the SDB file from C:WindowsAppPatchCustom, rather than using the sdbinst -u <guid> command to uninstall properly. Whilst attempting to re-run this command I was hit with the following error;

This error was preventing me from using sdbinst to reinstall the SHIM.

The solution is pretty simple – there are two locations in the registry that need removing;

• HKLMSoftwareMicrosoftWindowsCurrentVersionUninstall<GUID>.sdb
• HKLMSoftwareMicrosoftWindows NTCurrentVersionAppCompatFlagsInstalledSDB<GUID>

Delete these and you will then be able to re-import your custom SHIM.

Thanks
SteveH

Whilst at a customer recently I had a requirement to run a ‘Diskpart /Clean’ at the start of a task sequence to remove any encryption on the drive, in this case McAfee. I have done this several times in the past however always hit a few niggles so thought I would blog to refer to in the future

The easiest way to do this is to perform the following;

1. Mount your Windows PE image(s) to a directory
2. Create a text file called ‘CleanPartitions.txt’ (for arguments sake), with the following content;
   • Select Disk 0
   • Clean
3. Copy this text file to ‘<Mounted Folder>WindowsSystem32′ (again, for arguments sake)
4. Commit the mounted folder back to the .WIM

In your task sequence, before the standard ‘Format and Partition Disk’ phase, perform the following;

1. Add a ‘Run Command Line’ task
2. In the ‘Command Line:’ text area, type;
   • diskpart.exe /s “%windir%system32CleanPartitions.txt”
3. Disable 64-bit file redirection
4. Save the task sequence

This should now run successfully and remove any encryption on the drive

It is worth noting that this will only work in a Lite-touch situation as you will need to either PXE-boot or use bootable media. There is a solution that McAfee have released that allows you to perform this end-to-end in a Zero-Touch situation that I will blog about soon.

Cheers

SteveH

I came across the following error message recently whilst troubleshooting an SCCM Distribution Point;

————————————————————————————————————————–
There was an error while performing this operation.

Details:
Filename: \?C:inetpubwwwrootweb.config
Line number: <LineNumber>
Error:  Cannot add duplicate collection entry of type ‘<XXX>‘ with unique key attribute ‘<YYY>‘ set to ‘<ZZZ>‘.
————————————————————————————————————————–

Client’s were downloading packages via SMB rather than over HTTP which prompted me to check if WebDAV had been configured… upon clicking on the WebDAV feature configuration page the error appeared.

Turns out this was quite a simple fix – WebDAV had been configured at the Server Level, rather than at the Site level which a) resulted in this error and b) seemingly broke WebDAV and was the cause of the issue with the DP. Simply delete the configuration at the Server Level, and set your configuration at the site level.

Thanks
SteveH

Whilst recently implementing out of band management for a customer, I had an issue whereby the out of band console would not connect to any provisioned system. The connection status transitioned between; connecting, busy, disconnected and the oobconsole.log file stated;

GetAMTPowerState fail with result: 0x80072EE9

The power control options provided by OOB worked fine, – however these utilise TLS authentication as opposed to HTTPS for the console. Certificates are often the cause of much headache in OOB and after some searching came across a rep on the Intel vPro website suggesting that if the AMT web server certificate (issued to all AMT clients) was issued by a subordinate CA then to attempt adding this into the trusted root certificates for the local computer (that is running the OOB console)

Hallelujah! The console then connected fine

A customer recently wanted to create a security right in Configuration Manager that allowed a user to create packages; both physical and virtual whilst restricting access to the other components in the console.

At first glance this seems a fairly trivial task – create a group and add it as an user security right in SCCM, then assign the required classes – in this case;

• Collection – Read
• Package – Full

This had the desired effect for physical packages however the option to create a virtual application package was gone.

Several minutes of adding each class one at a time found that the ‘Site’ class with ‘Read’ and ‘Manage SQL Commands’ is required to display the option to create a virtual package. This complicates things a little as it allows users to make changes to certain attributes in the ‘Site Settings’ section – to mitigate this I added instance security rights to the primary site node giving the group I had created no permissions.

Cheers,