Each new update of ConfigMgr I will start a new entry for anything specific to that version I want to test or make notes of.
- The Windows 10 Servicing Plans now include filters so you can control which upgrades are downloaded automatically based on Language, Required, and Title. Excellent
- When you start an “older” ConfigMgr console, it tells you that you need to update it, and will then do that update for you. Excellent
…more to come
Update 21/7/2016: It’s quite likely I will be skipping 1602 and going to next update instead (1607?) after we had some other environment issues that needed to be sorted out first.
Other adventures:
Annoying stuff I figured out (or am trying to) 
Console is slow as mud too……
That’s not something I’ve noticed. If anything I’d say it’s noticeably faster.
Are you running it on the Server itself or remote? Server/SQL have enough memory? SMS Provider overloaded processing other requests?
Found an issue when the upgrade from 1511 to 1602 didn’t quite go to plan. Only a small handful of our Distribution points actually upgraded. Most were stuck with an error in dismgr.log: “the distribution point is not installed or updated yet”
The cause was the SNMP service having a lock on a couple of files in the SMS_DP$ directory.
Stop/Disable the SNMP service, restart the SMS_EXECUTIVE service (not sure if it’s required, but it seemed to help) and then wait (and keep waiting – around 25 minutes max) for the timer to reevaluate if the distribution point needs an update. Distmgr.log seems to track most of this.
That sounds very…odd. I can’t imagine why the SNMP service would have a lock on anything, especially in the SMS_DP$ folder, or why that would have prevented it updating.
Is this an issue you have raised with Microsoft or do you have a link to a reference article about this?
Specifically it was ‘smspxeperf.dll’ and ‘ccmperf.dll’ which are both performance counters which I assume SNMP was hooked into.
Didn’t raise it with MS (only worked it out last night).
Once we stopped the SNMP service, the upgrade occured without an issue. Thought it might be of benefit to anyone reading and possibly experiencing the same issue.
ok, I guess that makes sense, and I wonder if a “reboot after upgrade” just to finish things off would resolve that also.
Was experiencing the same issue. Can confirm that stopping the SNMP service removes the lock on the smspxeperf.dll file and the upgrade of the DP was then successful. Thanks for the tip!
Glad it helped!
Have you tested various WinPE peer caching scenarios yet? I have set up the variables and client settings correctly so the pxe PE client finds the content in a Peer’s cache and adds it to the Peer Content Server per the smsts but in the end still choses the distribution point over the peer cache. Does this not work if the wim is set to allow multicast or is it because the distribution point link is set to fast on the boundary group? Our network has some serious QOS in play for other services such as VOIP which significantly reduces our multicast speeds. I was hoping on Vlan peer caching between machines would be a lot faster than scheduled multicasts but it seems to always pick the distribution point? (CAS.log on Peer Host and SMSTS.log on client show both are ready for the peer cache connection)
Thanks!
I haven’t installed 1602 yet, and we aren’t using multi-cast or peer content sharing. These are all things that have come up in recent conversations though so I may be looking at them in the near future.
At the current time though I don’t really have any suggestions to offer.
FWIW… I ran into issues after upgrading from 1511 to 1602, regarding your comment about console upgrade requirement:
I would like to share my experience with a menacing problem with clients not performing hardware inventory and falling out of active client state. 3 months after opening a ticket with Microsoft, and 1 week after getting an SEE on board, we discovered that our MP was having WMI issues. The reason for this was because some loving administrator that I inherited SCCM from installed a Console on the MP server. Our MP server is separate from our Primary Site server. This caused the client to not update because the console was not updated (I didn’t realize I needed to update it). This caused a domino effect and a mismatched version between the Primary Site and the MP begun showing the WMI errors… long story short, clients couldn’t get the policy to run Inventories, and therefore became Inactive, then moved to Client=None… So once we discovered this, we upgraded the console on the MP, it in turn upgraded the client (a reboot was required for the upgraded console) and voila! Now I have a bunch of clients to repair and can move on with my life!!
Wow, that’s a nasty one. I know there are shared binaries with the client agent and the MP so they have to be in sync, but I never would have thought the console would also have that problem.
I had some MP issues with clients not upgrading, but thankfully we have been careful at locations where consoles are installed.