RSS

Monthly Archives: November 2013

Software Updates: what’s in a name?

Recently, at one of my customers I had quite a challenge regarding Software Updates by Configuration Manager 2012 SP1.

The SUP was working like a charm, synchronizing and downloading updates worked perfectly, no strange issues whatsoever on the server side.

However, clients were not able to communicate with the SUP. Both client versions used, Windows XP x86 and Windows 7 x64, were affected.

After manually kicking off the action Software Updates Scan Cycle I took a look at the WUAHandler.log I found some lines that caught my attention (the original domain name has been replaced with domain1.local for company policy reasons):

Its a WSUS Update Source type ({DB9CF52D-3200-405C-B6F3-6A6F0A2519A9}), adding it.    WUAHandler    15-11-2013 16:41:01    5748 (0x1674)

Existing WUA Managed server was already set (HTTP://SCCM001.DOMAIN1.LOCAL:8530), skipping Group Policy registration.    WUAHandler    15-11-2013 16:41:01    5748 (0x1674)

Added Update Source ({DB9CF52D-3200-405C-B6F3-6A6F0A2519A9}) of content type: 2    WUAHandler    15-11-2013 16:41:01    5748 (0x1674)

Scan results will include superseded updates only when they are superseded by service packs and definition updates.    WUAHandler    15-11-2013 16:41:01    5748 (0x1674)

Search Criteria is (DeploymentAction=* AND Type=’Software’) OR (DeploymentAction=* AND Type=’Driver’)    WUAHandler    15-11-2013 16:41:01    5748 (0x1674)

Async searching of updates using WUAgent started.    WUAHandler    15-11-2013 16:41:01    5748 (0x1674)

Async searching completed.    WUAHandler    15-11-2013 16:41:04    4708 (0x1264)

OnSearchComplete – Failed to end search job. Error = 0x80244019.    WUAHandler    15-11-2013 16:41:04    5748 (0x1674)

Scan failed with error = 0x80244019.    WUAHandler    15-11-2013 16:41:04    5748 (0x1674)

I found some similar behavior in the WindowsUpdate.log file (ignore the timestamps, they’re not relevant):

2013-11-15    16:41:03:979    1608    1450    PT     + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = HTTP://SCCM001.DOMAIN1.LOCAL:8530/ClientWebService/client.asmx

2013-11-15    16:41:04:010    1608    1450    PT    WARNING: Cached cookie has expired or new PID is available

2013-11-15    16:41:04:010    1608    1450    PT    Initializing simple targeting cookie, clientId = 7ad1acfb-56f2-4342-a612-476f84027010, target group = , DNS name = glnlpcm154.res.activdir.net

2013-11-15    16:41:04:010    1608    1450    PT     Server URL = HTTP://SCCM001.DOMAIN1.LOCAL:8530/SimpleAuthWebService/SimpleAuth.asmx

2013-11-15    16:41:04:010    1608    1450    PT    WARNING: GetAuthorizationCookie failure, error = 0x80244019, soap client error = 10, soap error code = 0, HTTP status code = 404

2013-11-15    16:41:04:010    1608    1450    PT    WARNING: Failed to initialize Simple Targeting Cookie: 0x80244019

2013-11-15    16:41:04:010    1608    1450    PT    WARNING: PopulateAuthCookies failed: 0x80244019

2013-11-15    16:41:04:010    1608    1450    PT    WARNING: RefreshCookie failed: 0x80244019

2013-11-15    16:41:04:010    1608    1450    PT    WARNING: RefreshPTState failed: 0x80244019

2013-11-15    16:41:04:010    1608    1450    PT    WARNING: Sync of Updates: 0x80244019

2013-11-15    16:41:04:010    1608    1450    PT    WARNING: SyncServerUpdatesInternal failed: 0x80244019

2013-11-15    16:41:04:010    1608    1450    Agent     * WARNING: Failed to synchronize, error = 0x80244019

2013-11-15    16:41:04:010    1608    1450    Agent     * WARNING: Exit code = 0x80244019

HTTP 404? That’s strange (the client must be kidding). The Windows Update client basically tells me that he cannot find the SUP. The SUP is on the same subnet as the client, it’s all LAN here…

Manually browsing to the URL gives me error 403. OK, that’s fine because I don’t have directory browsing enabled. At least I know it’s there…

Initially, I verified if everything was configured correctly. After I confirmed this was the case, I concluded the issue was caused outside Configuration Manager 2012 SP1.

After a lot of digging, I learned the customer uses a proxy server. They use a wpad.dat file which is deployed by DNS. The wpad.dat file tells the client to bypass the proxy server for local addresses with the dns suffix domain1.local.

I found similar behavior other admins have in the following links:

http://social.technet.microsoft.com/Forums/systemcenter/en-US/95aa4832-ab89-45fd-b444-9f68a0ee2e44/software-update-agent-using-proxy-with-wpad?forum=configmgrsum

and

http://social.technet.microsoft.com/Forums/systemcenter/en-US/0abd07d9-875a-4f0f-8d34-346fa66d2ca7/sccm-client-sum-agent-sets-wuserver-to-uppercase-causes-http-error-407-proxy-authentication?forum=configmgrsum

Typical error codes are mentioned in the following KB article:

http://support.microsoft.com/kb/896226/en-us

In the log files, however, I noticed the URL used has all capital letters. Then it hit me…

For the proxy settings: domain1.local is NOT the same as DOMAIN1.LOCAL.

The proxy server is configured to go to the Internet if direct access is not applied, in other words the application is told to go outside. This means the Software Updates Client, which uses the WinHTTP settings by IE, will attempt to locate the SUP somewhere on the Internet. Knowing the URL is on the LAN, the client going outside will not be able to find the server and generates error 404 as a result.

After discussing this issue with the admin responsible for the wpad.dat file, he added the DOMAIN1.LOCAL on the bypass list. Restarting the client machine caused the wpad.dat file to be reloaded. After retrying, the client was able to tell which updates he needs and the available updates poured in pretty nicely.

 

OpsMgr 2012 R2: first impressions…

Recently I was able to make an attempt to install OpsMgr 2012 R2 in a lab environment. I was particularly interested if deploying and initial management was significantly different compared to its predecessors. To be short: it isn’t…

I’ve decided to limit my testing by importing the Active Directory MP and a few network devices using the Xian SNMP Simulator from Jalasoft. Kevin Holman’s blog post on how to use this Simulator still works in OpsMgr 2012 R2, the post is available at the following website:

http://blogs.technet.com/b/kevinholman/archive/2012/02/17/test-demo-opsmgr-2012-network-monitoring-with-jalasoft-s-network-device-simulator.aspx

A good place to get some more first impressions is checking what’s new in OpsMgr 2012 R2. You can find this overview at the following website:

http://technet.microsoft.com/en-US/library/dn249700.aspx

Two particularly new features caught my attention:

  • A new Agent which completely replaces the old one;
  • Fabric Monitoring.

The integration between OpsMgr en VMM becomes much closer with this new feature. I have to admit this is something I really need to investigate when I have time and resources.

Personally, I am convinced that VMM is the starting place when building pristine Private Cloud environments based on Hyper-V. There’s room for debate if Bare-metal Deployment is something you need. MDT 2013 can do some very nice things on that part as well, it does require some manual labor when not using Bare-metal Deployment but it allows you to deploy much more than just a bunch of Hyper-V hosts.

I have to admit that this is something that really caught my attention…

I will post this in a future blog if I have figured it all out.

Feel free to your findings if you already had…

 

ConfigMgr 2012 R2: Thoughts on recommended site deployment…

Recently, on November 1st 2013, I attended a session organized by the Windows Management User Group (WMUG) Netherlands. This session was something special for me because the topics discussed were all related to the new features of ConfigMgr 2012 R2. What made it extra special was the presenter: Wally Mead.

Wally gave us a good overview of new features of ConfigMgr 2012 R2, the part that I considered the most important is deployment of ConfigMgr 2012 R2.

An overview of what’s new in ConfigMgr 2012 R2 is available at the following TechNet location:

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

When the presentation was over I took the opportunity to ask Wally a few questions that bothered me about hosting the Site Database. In some of my projects in the recent past I’ve had quite a number of political battles regarding SQL for ConfigMgr 2012 RTM/SP1/R2. I’ve had customers who had some political issues regarding high availability of the Site Database. If you want your Site Database to be highly available, then building a typical 2 (or more) node cluster with shared storage will provide that for you. Unfortunately, other solutions such as SQL mirroring or AlwaysOn are not supported. The following TechNet location shows this:

http://technet.microsoft.com/en-us/library/gg682077.aspx#BKMK_SupConfigSQLDBconfig

Wally explained to me that AlwaysOn has never been tested and to a certain degree I understand why. ConfigMgr 2012 itself is not ‘cluster-aware’, however your site infrastructure can contain multiple servers and quite some roles can be placed more than once.

I explained to Wally that in general my recommendation is installing an SQL runtime locally on the site server. In most cases, you can use Standard Edition because that is included in the licensing of System Center 2012 Suite (as long as the runtime has System Center Databases only) so no additional license costs will be charged. Appearantly, my recommendation is the same as Wally’s. I will not go to such great lengths by saying ‘because Wally said so…’ in my recommendation, each deployment has different requirements but I prefer to stay as close as possible to the recommended setup…

One final question I asked was security. The TechNet page displays it is a SQL best practice (note to Microsoft: you use the term ‘recommended practice’ nowadays) to use a user account for the SQL Services. Most of the time, I recommend using the local SYSTEM account to start the SQL services, especially when the SQL runtime for the Site Database is installed locally.

I’ve been doing designs and deployment for customers who have clients between 250 and 50000. Based on the questions I asked about deployment I’d recommend the following:

  • Try to stick to one stand-alone Primary Site unless you need to manage more than 100000 clients or political reasons would prevent you from doing so
  • Try to install SQL locally on the Site Server, especially if you can install ConfigMgr 2012 R2 on a virtual machine which has its own failover capabilities
  • Use the local SYSTEM account to start the SQL services
  • I would still stick to integrating MDT because of the added functionality. Even though some things are now available natively, you’d still miss the holistic approach MDT offers.

I would like to thank Wally Mead and the WMUG crew for making this session possible which gives me more insight on the recommended practices for deployment. It would certainly make my life and the ones from my customers much easier.

 
 
Steve Thompson [MVP]

The automation specialist

Boudewijn Plomp

Cloud and related stuff...

Anything about IT

by Alex Verboon

MDTGuy.WordPress.com

Deployment Made Simple

Modern Workplace

Azure, Hybrid Identity & Enterprise Mobility + Security

Daan Weda

This WordPress.com site is all about System Center and PowerShell

IT And Management by Abheek

Microsoft certified Trainer -Abheek

Heading To The Clouds

by Marthijn van Rheenen