All posts by Bondy

So you’re looking forward to upgrading to the next CB version of SCCM and growing frustrated at the fact there is nothing appearing in Updates and Servicing pane. In fact, there should be several hotfixes showing in addition to the latest and greatest version of ConfigMgr. But….nothing.

You can be logged in as a full administrator and nothing will appear!

SOLUTION:

Open the console as the user which installed ConfigMgr in the first instance. Failing this (user has since been deleted, etc) go to Administration | Security | Administrative Users and look for a user that has All instances of the objects that are related to the assigned security roles selected. The chances are, that the user you are having problems with doesn’t have this selected (yes, even if they’re a full admin) and this is the crux of the problem.

Now, open the console with the user who has this permission and you should now get a message saying that there are updates available. Go to the security node and make the appropriate changes described above to the users or groups that you wish to have access to this view.

A really quick post on an issue I had the other week.
The environment was https and all appropriate certs were in place. The production environment was working perfectly but in dev, when we used the FQDN to reach the report server we kept getting prompted for credentials. After double checking everything was set up exactly as I’d set it up for prod I found the credentials kept appearing. I tested the scenario without https and there were no prompts.

RESOLUTION

I added the site to the local intranet sites in IE and the prompting went away. A GPO might be called for if you experience this in an enterprise environment.

I ran into this problem recently at a client where we’d installed SCCM 1602 with full HTTPS communication throughout. One of the requirements was to deploy software and software updates to clients on the internet as well as the intranet. All went pretty much according to plan until I put a laptop on the internet to test deployment of said software. The issue I faced was that whatever I did, I couldn’t make the laptop drop to Currently Internet from Currently Intranet. Looking at the LocationServices.log confirmed my suspicions: it was trying to contact an MP on the internal network.

During my investigations I looked into what criteria ConfigMgr used to discover if it was on the internet and found the answer here:

When the client detects a change in network, this kicks off service location to find its intranet management point (the default management point in its assigned site or proxy management point if it’s within the boundaries of a secondary site that belongs to its assigned site). If service location fails, the client deduces that it must be on the Internet and so tries to communicate with its assigned Internet-based management point. The assigned Internet-based management point always directs the client to the Internet-based site systems in the site, and never to intranet-based site systems or to Internet-based site systems in another site.

So I looked at my default management point. This was also set (via an alias) as the internet management point (owing to the IP policy here they don’t really ‘do’ DMZs but that’s another story). So what was happening? Well essentially when the local network was disconnected and the computer was switched over to an internet connection, it wasn’t able to differentiate the default MP from the internet MP and hence thought it was still on the local network.

The Solution

I changed the default Management Point from the internet facing MP to a local MP that wasn’t accessible via the internet. This allowed the client to figure out that it was no longer on the local network and change over to the internet. Once this happened, it was then able to pick the correct MP and the correct DP to talk to and order was once again restored. I guess this isn’t a common scenario but something to look out for if you’re experiencing the problem described.

OK so Microsoft have released another set of firmware updates which are always welcome. I’ll admit I installed them and haven’t noticed a great deal of difference although possibly there maybe an improvement in battery life. Jury’s out on that but it’s a definite possibility. I am a heavy user with several VMs regularly running under Hyper-V in the background, usually a DC plus an SCCM server with all the roles installed and maybe a workstation client too. I am used to bad battery life and I think it may have improved.

I digress. I’m sure there’s plenty of extra stability goodness included in the new update but I am here (unapologetically) for a moan. This post is really an update on my previous Surface post (http://www.simonbond.net/?p=226) regarding the Samsung SSD. If you’ve not read it already then I suggest you do but the crux of it is this: the Surface 4 usually comes with a Samsung SSD which by default has fairly slow write times. When I say slow, up to 150 MB/s. For an SSD on a laptop type device this is rubbish. I explain in the linked post that this can be fixed with a driver update (and I have published a new link to this driver as it no longer seems to be accessible from the Samsung site). In any case here is my issue: The new update pack (May 2016) seems to revert the write speeds back to default , ie sub 150 MB/s.

Not sure what’s going on here but if you re-run the firmware update we’re back in business. Might be something to think about testing for all future firmware releases.

At the time of writing there appear to be very little on the internet about this particular configuration.

In short, we needed to use the MultiSubnetFailover option string with our SQL AOAG making up the CM2016 back end. We have two SQL DBs, one in London and one in Slough. As one might typically expect, these exist on separate subnets. After hunting around the internet to try to ensure the supportability of this configuration it quickly became clear that a call to Premier Support was required to confirm. In particular, we were interested to know whether the ODBC System DSN driver should remain the same on the site server. By default this uses an old version which doesn’t have the MultiSubnetFailover checkbox available. We figured this might need changing to the newer 11.x native client when AOAG were used over separate subnets. There was an awful lot of to-and-fro between ourselves and Microsoft and it was clear this was an area where there was little clear knowledge. We did finally prize an answer out of them however and the following is an edited transcript of the outcome:

We wish to know if SCCM 1511 and 1602 should be able to talk to such a multi-site SQL cluster OK?

Should we make SCCM use the “SQL server native client V 11.0” ODBC connection “system DSN” connection which has a check box that seems to have “multisubnetfailover” option or the default SCCM installed “SQL driver” for ODBC connection?

ANS: We should not be making any changes to the default configuration made as part of the ConfigMgr installation. ConfigMgr does not support SQL Server Multi-subnet clustering.

If we upgrade SCCM from 1511 to 1602 (or to a later version in future) will the upgrade make the site server use the “SQL driver ODBC” connection again, needing a manual change to SQL native client again?

ANS: We should not be altering the default configuration at ODBC

[PS Engineer] wrote the following “…SCCM Components make use of dll’ (some components) andSQL Server native Client both. Native Client will get updated as per SCCM need, and we can leave sqlsvr32.dll’ as its default version.”

Our response: But slqsvr32.dll, does it have the multisubnetfailover option? We cannot see this. Where and how do we configure ALL the components to use multisubnetfailover on primary site server and other component servers as appropriate?

There has been a lot of talk about the use of SQL AlwaysOn Availability Groups (AOAGs) from SCCM 2012 onward but it wasn’t available in any iteration of this version and promises were made by Microsoft to include this is as a feature in 1511. Indeed it seems to have been planned and implemented in the Technical Previews but evidently didn’t make it into the final official release of 1511. Given that officially* you need to go via 1511 to install 1602 this is very annoying for anyone wishing to use this feature as a number of extra steps are required. Below I try to clear up much of the contradictory information available at present (May 2016) on the internet.

A number of websites run by respected MVP’s continue to suggest availability in several 1511 versions:

Technical Preview 1511 – This version is also known as the Configuration Manager Technical Preview 4. It represents a baseline for Technical Previews that begin with the release of the current branch for System Center Configuration Manager, version 1511…

This is where it gets interesting because Technical Preview 4 covers a number of separate releases which flank the ‘official’ 1511 release on Dec 8th 2015:https://buildnumbers.wordpress.com/sccm/
Well that that clears it up then.

After filtering through a good deal of contradictory information, it appears that SQL AOAGs made it into the 1512 TP4 version and that 1602 is the first official CB release to have full support.
So to be clear, when installing 1602 and above from scratch, install 1511 first by pointing to the single DB instance then change to AOAGs later via the procedure below.

If you don’t, and you are using the Dec 8th (official) release of 1511 then when adding the AV Listener you’ll see the following error message:

And nobody likes to see that 🙂

* I hesitate to say this but it is perfectly possible to install 1602 direct from certain media sources** for 1602.This is not supported and therefore not recommended, I am informed one of the side effects of doing this is that you’ll not be able to update in future. There may be other, undocumented side effects too.

** Media I obtained came from an unconfirmed source althoughit is possibleit may have been from CD.Latest (I didn’t originally source it so can’t confirm for definite). Basically don’t do it if you want a supported environment!

So in a lab I upgraded my SCCM 2012 R2 SP1 instance to 1511. This is a Hyper-V environment running on my Surface Pro and I have SCCM, SQL and the SCCM admin console running on the same VM.
The upgrade itself appeared to go smoothly but when I opened the admin console I just got the grey screen telling me I was unable to connect and that I should check I had permissions and that the SMS provider was installed and available, etc. Obviously it was, it was on the same machine and I had been working with it 20 minutes beforehand.

My immediate reaction was something had gone wrong with the DB upgrade. I hadn’t run the /TestDBUpgrade switch as this was very much a test environment and I didn’t have another server I could quickly and easily test it with. I did however take a snapshot and reverted back. A few tweaks here and there and a re-run of the upgrade produced the same result. Then I decided to test whether this was actually a problem with the installation or simply a problem with the console.
I decided to try and build a machine off this install (PXE boot) and sure enough it built perfectly.
Next, I installed the 1511 console on another VM (my lab DC in this case) and sure enough again, it connected perfectly.
Great.
Next step, check the console logs, in particular the SMSAdminUI.log file under C:\Program Files (x86)\Microsoft Configuration Manager\AdminConsole\AdminUILog. Under here I noticed that there were a number of performance counter errors eg as below:

[1, PID:844][04/08/2016 11:11:59] :The performance counter ‘# images’ was not found
[4, PID:844][04/08/2016 11:12:01] :The performance counter ‘# result objects in memory’ was not found
[4, PID:844][04/08/2016 11:12:01] :The performance counter ‘# exceptions’ was not found

SOLUTION
Seems the upgrade broke the performance counter settings in some way so this needed fixing:
1. (Important) Open a command prompt and CD\Windows\SysWow64
2. LODCTR /R (ensure you are in the dir path above or you are likely to get error code 2).
3. Reinstall the console from the 1511 upgrade setup.
4. Et Voila, (hopefully) all should start working again.

Thought I’d do a quick post on this as there is precious little to be found in forums about this task sequence ‘bug’. I say bug, really it’s probably just lazy programming (I haven’t checked the specifics but the evidence leads me to believe this is the case).

Anyway…the scenario is this:

ENVIRONMENT:
SCCM R2 SP1
MDT 2013 U1

MDT-infused Client Task Sequence goes all the way through until it hits the Gather step under the State Restore phase. At this point you are hit with:

In this case the Set Variable For Drive Letter step under the Install section had set the OSDPreserveDriveLetter task sequence variable to TRUE which caused my OS disk to be set to X: for some reason! I suspect the same may happen if the OS had been installed on another drive other than C: but I haven’t tested this so can’t say for sure. Equally it appears to happen only with Gather Only Local Data. In any case the fix is to ensure you are installing to C:

Just felt I needed to write a post in for this as I have spent a very frustrating morning trying to get a perfectly good (and fairly simple) run book to work with ConfigMgr 2012 R2 / MDT 2013.

All ran fine in the runbook tester but once I added the step to a task sequence and ran it my SMSTS.log file looked as follows:Now the 10801 error seems somewhat ubiquitous regardless of what the actual issue is. For example, you’re as likely to receive it for a run book you’ve forgotten to check in as you are for using an account without publishing permissions. Unfortunately given how commonly this error seems to occur, there appears to be precious little about it on the internet. Indeed I have to confess I never found the proper solution to fix the problem. Anything vaguely approaching a solution seems to centre around running the following SQL script on the Orchestrator database. It might be worth trying this before attempting the workaround below:

WORKAROUND

I did however fix my problem nonetheless. The ‘solution’ for me was simply to create a brand new run book and recreate my previous steps. Once I’d done this, I tested again against a dummy task sequence before putting into my live sequence and all was well. I apologise this isn’t a proper ‘fix’ for the issue, but as I say at the time of writing there is very little on the subject and nothing I could find with my specific errors. Hopefully it will be quicker just to try this than spend several hours banging your head against a wall.

There are a 101 ways of deploying software updates out there and you’ll undoubtedly get a different answer on the best way to deploy updates from every ConfigMgr admin you ask. Indeed it obviously depends on the environment and company politics how best the solution is implemented. This is my tuppence worth.

As an admin, you have enough to do in setting up the required updates in the first place. In many environments you’ll then have to raise the necessary change requests and all the headaches that entails. Then there is the deployment itself:
“Why did it install that?”
“Why didn’t it install that?”
My solution to this is to move the onus to the application or server owner to set up when their computers are patched.

1, STRATEGY:

Select you maintenance window(s). Ensure the window is of sufficient length to take into account all the updates that need deploying. If a ‘hard’ maintenance window is in force, bear in mind you might not finish installing and rebooting before it closes if it is set too short. For my example I will select three per day for different deployment types. This doesn’t mean there will necessarily be computers populated in all three collections, but the option is there. Agree these with all interested parties first. For example:

By duration I’m talking about how long to complete the deployment to the enterprise. For me, there are two scenarios here. I will typically roll out patches to the servers and/or workstations in my test domain before rolling out to live. The duration for the full rollout is 14 days for each environment (test/non prod and production). This (usually) leaves a few days in between patch Tuesday to download the new updates and deliver the update list for the coming month to interested parties to approve, before rollout on the following Sunday (‘Patch Sunday’). In many situations you may not have the advantages of a test environment to hand. In these situations you may potentially argue that a longer rollout period was necessary. However there are few situations I have ever seen where a 14 day cycle isn’t sufficient if proper testing is put in place.

3. DEFER OWNERSHIP:

As alluded to earlier, IMO the onus should be on the SCCM admin to set up the job but after that it should be up to the application owner or server team to administer when their servers are patched. Ideally the patch window for the server should be set at the server build stage and should be specified in the original request.
My approach to this is to ensure all the software update collections have a query rule assigned which defines a particular AD group that can be updated by the interested party. Responsibility then falls squarely on the owner for any problems related to when the machine is updated.

4. AD GROUPS, QUERIES AND COLLECTIONS
This is how I set up my collections in SCCM along with the queries and groups.EXAMPLE AD GROUP:
Name: PR1-SCCM PRD-07-2300-0100 (Site PR1, Prod environment, day 7, 2300-0100)EXAMPLE COLLECTION:Software Updates – WK1 – Saturday – 2300-0100 or Software Updates – WK2 – Wednesday- 2300-0100EXAMPLE QUERY RULE:select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where SMS_R_System.SystemGroupName = ‘DOMAIN\\PR1-SCCM PRD-07-2300-0100’ and SMS_R_System.Name not in (select distinct SMS_R_System.Name from SMS_R_System where SMS_R_System.SystemGroupName = ‘DOMAIN\\MW Exception Group’)
Note:DOMAIN\\MW Exception Group represents a group that a computer can be dropped into if for some reason it needs removing from its usual schedule temporarily.

5. NO REBOOT GROUP
In addition to the three daily maintenance window collections, another daily collection I have set up is one with no reboot. Indeed this is of particular interest to certain application owners who only have a narrow window where servers can be down. They take the responsibility on themselves to manually reboot these machines at a time convenient to them.

6. ADMINISTRATION
So…if should you decide the above all sounds like a great idea (that’s a big if, but go with me here) we’re talking about over 60 collections to deploy updates to. That’s going to take all week to set up isn’t it, particularly if there are a lot of update to deploy? Well yes, it is. If done manually. Powershell would traditionally be your friend here and when I first started this, that is exactly what I was using. What I found in practice though was even with this I wanted to see what was going to happen first and again you could write scripts to do this too. What I decided on though was to write a tool that would do everything for me. When I say everything, I am including creating collections, hard maintenance windows (if required), AD groups, queries and of course the selection, deployment schedule and deployment of the updates themselves. This tool is adaptable for different environments and should make the whole process very simple. Whilst I take no responsibility for how you use it in your environment, I have used it in live and prod environments at clients I have consulted and all sorts of different test environments. I include the download and source code at the end of this blog.

7. TO WRAP UP

This blog has detailed my specific approach but the high-level is really what it’s about. As I mentioned in my opening paragraph, one size does not fit all but I do believe some of the pressure (and work) can and should take a shift sideways. Some computers you’ll most likely always have to deal with, eg workstations/laptops. The systems that cause the most headaches though are the servers and I firmly believe ownership can and should be shifted here. It won’t work everywhere but it’s all about changing culture.