thanks. On Fri, Sep 9, 2016 at 2:30 PM, Miller, Todd <[email protected]> wrote:
> 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:listsadmin@lists. > myitforum.com] *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. > ------------------------------ > >
