Yes, we skipped 1602 and went to 1606 in our Dev environment, but due to various change freezes, conflicts with other projects and change management delays we have decided we will be going from 1511 direct to 1610 in Prod.
The Dev upgrade went OK (using the “FastRing” powershell script) however it was then announced there were some additional bugs found and a newer 1610 installed was released. The updates though have not as yet been posted to update the people that had run the original 1610 install…
So now I’m hoping the final 1610 release happens in time for the scheduled change we have set before Christmas.
I’m am however also in the process of building *another new* Stand-alone ConfigMgr Primary which will be the 5th separate CM hierarchy in the same domain, and the 8th hierarchy (incl Dev). This one is only tiny though, only managing about 6,000 devices.
Install will be using the latest Win10 ADK and the latest MDT
Interesting things of note:
- Big changes around Boundary configurations
- No more fast/slow boundaries, but you do get the extra “default” boundaries
- I can see a lot of uses for these new Boundary features, however for my current environment the potential to flood the WAN links is a very real possibility if we get it wrong
- Probably my most wanted feature is being able to go straight to the monitoring view of a package for distribution status rather than the link just taking you to the monitoring node 🙂
When following the install progress, these logs will be the order to follow, starting at the CAS (if you have one) and moving on to the Primary sites.
- C:\ConfigMgrPrereq.log
- C:\ConfigMgrSetup.log
- Logs\CMUPDATE.LOG
- HMAN.LOG and DISTMGR.LOG
19/12/16
The day has finally arrived and the 1610 update is now being applied into production. Here are some running thoughts as they occur to me while waiting:
- We have a large site, and doing the backup beforehand is a really good idea, but it takes a *really* long time when it isn’t happening after hours. In this case 3 hours instead of the expected 1.5. So that’s something to keep in mind for next time
- The lack of update progress is still frustrating. I had expected to see more activity in CMUPDATE.LOG, but C:\ConfigMgrSetup.log on the site server in progress is the place to be
- The update and servicing node is sitting on “Checking prerequisites”
- Check C:\ConfigMgrPrereq.log on the site server to see what is happening
- There are no logs on the CAS that seem to say what is happening or where to look for current activity during the early waiting phases
- On the Primary sites I found some action in the DISTMGR.LOG
- There is finally something happening in the HMAN.LOG on the CAS. Looks like it’s polling all the DPs, which will take a while as there are 1800+
- I think I shall do some digging and/or annoy people into an explanation fo what logs should be involved in monitoring progress
- The update and servicing node is sitting on “Checking prerequisites”
- [Insert expletive here] Pre-req check just failed at “Verifies that no active source hierarchy is currently configured for migration”
- So there’s another thing I forgot for my checklist. Disable the Source Hierarchy Data Gathering in the Migration node before starting the update!
- At least we only got “Warnings” for the Primary sites because of inbox files older than a day. That’s not unusual for us given the volume of stuff that sometimes gets orphaned, so I should probably make a point to clean up those files before doing future updates. For reference, they were all old files in DESPOOLR.BOX/Receive
- After retrying, the “Update Pack Installation Status” now shows the CAS stuck on “Waiting” with detailed status of “Waiting for parent to finish installing” (what parent?)
- CAS CMUPDATE.LOG is looping “Waiting for current site server to be ready to apply updates:[GUID]”
- Noticed that “Retry installation” is now available from the Updates and Servicing Node again. Hmm, wonder why it just has a “waiting” status if it’s actually not waiting at all. Perhaps in a way it is waiting
- Interesting that doing a retry now tells me it will ignore any warning messages, which is what I was going to do anyway, but curious that it’s not an option 2nd time around
- There should have been something to indicate that it wasn’t actually waiting at all, but had finished. This seems to be a bit of bad guidance presented in the GUI
Other Adventures:
Annoying stuff I figured out (or am trying to) 
Is there a chance when you upgraded that you ran into an endpoint antimalware policy being moved or deleted and now you cannot edit it???
If you right click it and go to properties it comes up with an error box saying
The requested object information could not be retrieved. Refresh the Configuration Manager console to verify that another administrator has not moved or deleted the object, or that the rol-based administration security scopes or security roles for the object or current user have not changed.
Clicking on details reveals
ConfigMgr Error Object:
instance of SMS_ExtendedStatus
{
Description = “Instance is not a valid client agent config”;
ErrorCode = 1078462208;
File = “e:\\cm1606_rtm\\sms\\siteserver\\sdk_provider\\smsprov\\sspclientagentconfig.h”;
(not sure why this…as I do not think it was version 1606 RTM as we installed from the cloud and there is no E drive on the site server)
Line = 1773;
Operation = “GetObject”;
ParameterInfo = “SMS_AntimalwareSettings.SettingsID=134217733”;
ProviderName = “ExtnProv”;
StatusCode = 2147749889;
};
–Double checked security Roles and they were the same…so I redid them just in case and added all the collections and security scope for their site.
–Noticed this on two of the policies but the rest are fine.
Any ideas? other than maybe someone actually did delete them?? These guys are not very active on their site and the one in contact with me is pretty much the only admin that is in the console…
Not an issue I’ve had. If you find some policies work and some don’t, then there may be a corruption. In most cases it’s easier to delete and recreate them. I’ve had similar policy corruption issues (relating to TS deployments) that Microsoft spent months troubleshooting, but they can’t “repair” all the linked references in the database so deleting the policy and orphaned DB references in the database become the only option.
I don’t know what the E: reference is, but as a guessed I’d say maybe it mounts a virtual drive (e.g. ISO/WIM) during installation that the update media is packaged in? I don’t know the specific reason for that one though.
Sometimes things get corrupted. check you don’t have any other errors in the policypv.log, and see if there are is a CrashDump folder in the logs directory that might indicate an unexpected shutdown at some point.
Scott, I have the same policy corruption in the Antimalware Policies. How do you fix them? What sql query do you used for delete the policies and orphaned DB references?
Best regards.
If you think you have corrupted policies the easiest fix is to delete and recreate them. If you suspect orphaned policy info then that’s a bit more complicated as it gets into the “editing the database directly” which is very unsupported and can cause more problems if not done correctly.
You may or may not find orphaned policies using the following queries, but I wouldn’t recommend deleting records without further guidance, and would strongly advise raising a call with Microsoft if things are that bad
select * from vAdvertisement where OfferID in (select OfferID from SoftwarePolicy where PADBID not in (select PADBID from PolicyAssignment))
Select * from ResPolicyMap Where PADBID in (select PADBID from SoftwarePolicy where PADBID not in (select PADBID from PolicyAssignment))
SELECT * FROM ResPolicyMap WHERE machineid = 0 and PADBID IN (SELECT PADBID FROM PolicyAssignment WHERE BodyHash IS NULL)