Thursday, 23 May 2013

SCCM2012 with SCUP 2011 - Move your database and make it shared

So as you can see, a lot of SCCM 2012 posts mainly due to the fact that I setup SCCM2012 from the begining to the end at my company, and experienced lots of challenges along the way, but it is all now running as a well oiled machine, with Endpoint Protection 2012, MBAM2.0 integration, Citrix Publisher Integration, WSUS, SCUP 2011 with Shavlik updates, pretty much the whole nine yards.

One of the requirements around here was to get SCUP 2011 working to be able to publish Adobe updates at the least. Since there are only a few live catalogue providers (Dell, HP and Adobe last I checked) this wasn't really a requirement per say, but in an effort to make the transition from SCCM 2007 to 2012 as seamless as possible, I took the challenge on to get this working.

As some of you may know, SCUP 2011 is a single user application by default. You set things up, everything is great, it works for you, but if anyone else wants to use it, then they have to set everything up as well. This includes having to add all update sources, WSUS and SCCM integration components ect. I didn't know this myself until I had a co-worker test out SCUP, and to my surprise it was completely empty, with nothing configured at all. I figured there has to be a way to make this all work, so I searched on Google and found a few very interesting posts which got me 90% there, but the other 10% took me a few more days to figure out.

As posted here, the database file that SCUP 2011 uses is actually stored under the user's profile, which can be moved to a different, shared location. In my case, the database file was located at this directory

C:\Users\EBLEND\AppData\Local\Microsoft\System Center Updates Publisher 2011\5.00.1727.0000\scupdb.sdf
I copied the file to the install directory where I installed SCUP 2011 as it is accessibly by all administrators, and modified the  Scup2011.exe.config file in the same directory to reflect the new location as described in that post I mentioned earlier.

            <setting name="SSCEDataFile" serializeAs="String">
                <value>D:\Program Files (x86)\System Center Updates Publisher 2011\scupdb.sdf</value>
Excellent I thought, this is now ready....but this was not the case. When a co-worker tried to open SCUP, he got an error "An error occured. Please refer to log file for details". I did a quick Google search and found this post where it explained that for whatever reason, a user or a group that is a member of a local administrator group, even if granted permissions directly to the SCUP folder, does not have access to access the database file. I looked at the permissions on the SCUP folder, and Administrators had full access, and I had my AD SCCM groups as part of the local Administrator's group, but it wouldn't work. The trick is to assign your AD SCCM administrator groups directly to the folder, after I did this, SCUP opened without issue.....I thought....more on this in a minute.

So as you can see, ConfigHelpDesk was granted full permissions on the SCUP install folder directly, even though it was already a member of the local Administrators group.

So all this work got me to about 90%...users were now able to login (one at a time) and see everything that is configured on this shared database. Great, so my work was done I thought. A few weeks later a co-worker was ready to publish something and the options were not there, so I was called in to take a look. Looked at the options, and sure enough, all the certificates, WSUS integration and SCCM integration is not even configured! So it looks as though the database holds some information, the configuration is stored somewhere else. I started to do some looking around, and stumbled upon this nicely named directory in my user profile:

I opened up this file  and sure enough, it seems like all of the configution for Certificates, WSUS and SCCM integration is stored here, and looks something like this:

<?xml version="1.0" encoding="utf-8"?>
            <setting name="EnableWSUSPublish" serializeAs="String">
            <setting name="LastKnownCertificateIssuer" serializeAs="String">
                <value>CN=certauthsa1, DC=auc, DC=ab, DC=ca</value>
            <setting name="LastKnownCertificateExpire" serializeAs="String">
                <value>3/21/2015 10:01:07 AM</value>
            <setting name="IsTimestampEnabled" serializeAs="String">
            <setting name="SigningCertSectionEnabled" serializeAs="String">
            <setting name="EnableCMIntegration" serializeAs="String">
            <setting name="LocalSourcePublishingFolder" serializeAs="String">
            <setting name="UseCustomLocalSourceFolder" serializeAs="String">
            <setting name="Height" serializeAs="String">
            <setting name="Width" serializeAs="String">
            <setting name="Left" serializeAs="String">
            <setting name="Top" serializeAs="String">
            <setting name="TrustedPublishers" serializeAs="Xml">
                    <ArrayOfString xmlns:xsd="" xmlns:xsi="">

I copied everything between <userSettings> and </userSettings> from the config file above and pasted it into the same Scup2011.exe.config file that we have previously modified with a new database location, replacing the empty fields with the same labels. Once I did this, every admin user could publish and all of the certificate, WSUS and SCCM integration configuration was there, in a truly shared way. Keep in mind that you still have to run SCUP 2011 with "Run as Administrator", otherwise it will not publish.

In addition, for every update category that you publish, that category or vendor name will need to be checked of as a "product" in SCCM 2012 console under Administraton > Site Configuration > Sites > Right click to Configure Site Components > System Update Point.

You will have to run "Synchronize Software Updates" function twice from within SCCM 2012 console to first get the update to show up in the list above to be checked off for synchronization, and then again to actually get the updates to show up within your update list in SCCM.

Somewhere along the line, I learned that we actually have an active Shavlik subscription, so I attached our SCUPUpdates catalogue from Shavlik into SCUP and can easily publish all 3rd party updates directly into our SCCM 2012 server. Here is a picture of the 3rd party products that Shavlik can patch via SCUPUpdates with SCUP 2011 and SCCM 2012

I didn't see any reference to this complete solution, so hopefully this is of use to someone.

1 comment:

  1. Fantastic guide, worked for us on our SCCM 2012 R2 server running SCUP 2011.
    Thanks for putting this up.