My case is now closed with premier. Autoupgrade will only function on clients within a boundary of a protected DP. The setting to allow clients to get the CCMsetup agent from a fallback DP was removed. So I either need to not use autoupgrade, or assign all clients to protected DP boundaries.
The autoupgrade feature is pretty nice, but it is hobbled greatly by the need to setup and maintain content boundaries. I will need to disable autoupgrade and do it the old fashioned way... Create collections of machines not on the current version of the agent and deploy the agent to them or use some other method of deploying the upgraded agent (GPO, startup script, carrier pigeon) I have added a "feedback" on connect if anyone feels like throwing a vote my way. https://connect.microsoft.com/ConfigurationManagervnext/feedback/details/3102353 From: [email protected] [mailto:[email protected]] On Behalf Of Miller, Todd Sent: Friday, September 09, 2016 10:03 AM To: [email protected] Subject: [mssms] Client AutoUpgrade CB1602 I am having a problem with the client autoupgrade process with ConfigMgr CB (1602) - it doesn't function for clients outside protected DP boundaries. I don't use site boundaries since I have only a single site. My clients are all assigned by the OS deployment process or by installation of the client using switches in the CCMSetup. I do have some content boundaries set up for certain areas, where I have DPs deployed and want to keep the deployment traffic contained to that building and not clog up the intra-building network backbone. There are many buildings/subnets/areas where the number of clients doesn't justify a DP. For those clients, I rely on 3 DPs in our datacenter that are not assigned to any content boundaries and are configured to act as "fallback" DPs. The problem I have run into is that the built in client autoupgrade process in CB1602 does not allow the client to be pulled from remote DPs. Those packages/programs/adverisements are auto-created and are hidden from the console. In addition, they are not editable even through WMI calls. They get created with "allow fallback" set to "false" so clients that are not in site boundaries (which do not exist) or are not in a content boundary (which is not always appropriate) do not get auto-upgraded. I have a case open with premier services and we are working through the problem, but I thought I would post here to see if anyone has some ideas. Has anyone else run into this problem, or does everyone have strict content boundaries or site boundaries for every potential client? A lot of times the network folks will spin up a new subnet for offsite VPN, or we might acquire a new affiliate that has a new IP range. I was happily configuring content boundaries for the IP ranges I "care" about (where there was a protected DP for those ranges) and leaving the rest of the IP ranges to "fallback" to the at-large DPs in the datacenter. By setting that simple flag "Allow fallback" to false in the built-in autoupgrade process and then preventing every conceivable way to change it (GUI, WMI, I even tried editing the DB table directly in my test environment) they totally have blocked me from successfully updating my clients to 1602. Of course all the clients that are inside content boundaries are happily downloading and upgrading the new CCM client agent. I feel like I am going to have to create a collection/deployment to send out the 1602 agent rather than being able to take advantage of the hobbled autougrade process. There used to be an "allow fallback" checkbox in the autoupgrade settings in the site hierarchy area. ________________________________ Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521 and is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If you are not the intended recipient, any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately and delete or destroy all copies of the original message and attachments thereto. Email sent to or from UI Health Care may be retained as required by law or regulation. Thank you. ________________________________ ________________________________ Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521 and is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If you are not the intended recipient, any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately and delete or destroy all copies of the original message and attachments thereto. Email sent to or from UI Health Care may be retained as required by law or regulation. Thank you. ________________________________
