Think I was more wondering about the content allocation, from DP’s using AD sites. But as Ryan said, I don’t think WinPE media will work with that. Or it inherits the DP’s AD site membership.
/A From: [email protected] [mailto:[email protected]] On Behalf Of Miller, Todd Sent: den 14 mars 2016 18:34 To: [email protected] Subject: RE: [mssms] Re: Boundary Groups gut check My environment has secure network ports, so I can’t use PXE and don’t have experience with that part of your question. When you build your boot image for USB or CD, you can choose “Dynamic Media” where the client contacts the defined MP which might pass the client to a different MP based on Site Boundaries. If you choose this one, it wont work if you don’t have site boundaries defined. – but why would you choose this if you have only a single site? Or “Site-Based media” in which you define which site the WinPE image should work with. If you only have a single site and don’t want to mess with site boundaries, then this is the option you use to create your media. I can tell you for certain that I do not have any boundary groups configured for site assignment and my boot media works to do OSD just fine without them. I always build my boot media using the “Site-Based media” option. The “Dynamic Media” WinPE boot media also requires an MP to be named when you create the media. I believe the MP listed can act as a kind of a proxy for “Dynamic Media” to read the ConfigMgr site boundary list (even if they are AD site boundaries) and re-assign the WinPE client to a different site in the hierarchy if appropriate – but I am not 100% confident of this last paragraph. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Andreas Hammarskjöld Sent: Sunday, March 13, 2016 1:28 PM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] Re: Boundary Groups gut check So while on the boundary check. How on earth does WinPE media deal with AD boundaries? Will it always be outside? Or will PXE use the boundary of the PXE Server? What about ISO/USB media? I am le confused. //Andreas From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Jason Sandys Sent: den 12 mars 2016 15:42 To: [email protected]<mailto:[email protected]> Subject: Re: [mssms] Re: Boundary Groups gut check Concur with Todd except for one case — you are using System Discovery and auto client push. Without a site assignment boundary group, newly discovered resources won’t get assigned to the site and thus auto client push won’t push to them. There are other ways to handle client installation though so this is definitely not a show stopper; e.g., if you are using OSD for all systems, then they all already have the client and this is moot. I think setting the default site in this case works also, but that’s a hidden, non-obvious setting that many folks don’t know about. J From: <[email protected]<mailto:[email protected]>> on behalf of "Miller, Todd" <[email protected]<mailto:[email protected]>> Reply-To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Saturday, March 12, 2016 at 8:31 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [mssms] Re: Boundary Groups gut check You don't technically need boundaries for sites in Configmgr 2012. Especially If you have a primary site only, and you tell the client what site to use when you install it, then you can skip site boundaries. But you do need to assign the site in all client setup scripts/command lines and install methods--automatic site assignment needs boundaries. On balance, for me it was easier to specify the site in my client installs than to maintain site boundaries. I still use boundaries for protected distribution points. I have DPs plugged directly into core routers out at the edge of the network, so I want to make sure each protected DP only serves the networks on the same core router and minimize Configmgr traffic going over the network backbone. If a machine is not in an assigned DP boundary, it will fall back to get content from an unprotected DP. So, in my opinion, unless you have multiple sites, and you expect clients to roam from site to site, there is real no need to define site boundaries. Theyre a hassle to maintain, and complicate standing up a test Configmgr site on the same networks as production (overlapping boundaries). All you gain with boundaries is automatic site assignment, which you easily overcome by assigning the site code when you install the agent, Sent from my iPhone On Mar 11, 2016, at 4:00 PM, Brian McDonald <[email protected]<mailto:[email protected]>> wrote: Even if you have only 1 Primary Site, correct? Thanks! ________________________________ From:[email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> on behalf of Krueger, Jeff <[email protected]<mailto:[email protected]>> Sent: Friday, March 11, 2016 3:55 PM To: [email protected]<mailto:[email protected]> Subject: [mssms] RE: Boundary Groups gut check Yep, that’s what we do. We have 1 Boundary group for site assignment and then have a bunch of groups for content. From:[email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Brian McDonald Sent: Friday, March 11, 2016 4:44 PM To: [email protected]<mailto:[email protected]> Subject: [mssms] Boundary Groups gut check I read some where that it is recommended to have separate Boundary Groups for Site Assignment and a separate Boundary Group for Content Lookup. Is this *really* the case and I'm wondering what others are doing and how this is configured in your environment? Thanks, Brian M. ________________________________ CONFIDENTIALITY NOTICE: This email contains information from the sender that may be CONFIDENTIAL, LEGALLY PRIVILEGED, PROPRIETARY or otherwise protected from disclosure. This email is intended for use only by the person or entity to whom it is addressed. If you are not the intended recipient, any use, disclosure, copying, distribution, printing, or any action taken in reliance on the contents of this email, is strictly prohibited. If you received this email in error, please contact the sending party by reply email, delete the email from your computer system and shred any paper copies. Note to Patients: There are a number of risks you should consider before using e-mail to communicate with us. See our Privacy & Security page on www.henryford.com<http://www.henryford.com> for more detailed information as well as information concerning MyChart, our new patient portal. If you do not believe that our policy gives you the privacy and security protection you need, do not send e-mail or Internet communications to us. ________________________________ Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. 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, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. ________________________________
