How do I remotely trigger the "find site" button RRS feed

  • Question

  • I have an SCCM 2012 R2 CU2 site, ABC, hosting hundreds of clients which are working fine.

    I installed a parallel SCCM 2012 R2 CU2 site, DEF, on a different server.

    I have removed an IP range-defined boundary and its corresponding boundary group from site ABC, and re-created it in site DEF.  I have verified via ADSI that the changes were published correctly in AD.

    If I open the configuration manager applet on a client within that subnet, the 'Site' tab indicates the currently assigned site code is ABC.  But if I click the 'Find Site' button, it immediately changes to DEF and stays there.

    How can I trigger the 'Find Site' button on the remaining clients remotely?  I don't want to have to log into each one, and I don't want to have to redeploy the client to all of them if I can help it.


    Monday, August 25, 2014 9:54 PM


  • http://gallery.technet.microsoft.com/scriptcenter/Change-sccm-configmgr-cf6e0327

    I did find this script though...

    • Marked as answer by HeyAdmin Tuesday, August 26, 2014 4:51 PM
    Monday, August 25, 2014 9:59 PM

All replies

  • Use right-click tools and assign to another site? 

    Maybe someone else knows if there is a WMI method that will do the same, but a quick look on google doesn't show me one...

    Monday, August 25, 2014 9:57 PM
  • http://gallery.technet.microsoft.com/scriptcenter/Change-sccm-configmgr-cf6e0327

    I did find this script though...

    • Marked as answer by HeyAdmin Tuesday, August 26, 2014 4:51 PM
    Monday, August 25, 2014 9:59 PM
  • I don't know if it can be triggered or not, never tried it or looked for it. However, there are other ways to reassign clients between sites. You can use the GP template that is provided to do so. You can send a script to them all to do so (a sample script was provided in the ConfigMgr 2007 docs I recall). 

    Wally Mead

    Monday, August 25, 2014 9:59 PM
  • The real question here is why would you do this?

    Are you permanently moving the clients to the new site?

    If so, why not use Client push from the new site? Alternatively, you can use a script as Wally suggested deployed from the old site:


    (or the link to the one that t.c.rich posted although they are materially the same)

    Jason | http://blog.configmgrftw.com | @jasonsandys

    Tuesday, August 26, 2014 1:08 AM
  • We are actually merging two sites (one for workstations, one for servers) into one site, which is built on a new VM using Windows Server 2012 and SQL Server 2012.  It's a distributed environment so if we can avoid pushing the full client over the WAN connections and just re-configure the one that's there (which is already 2012 R2 CU2), that would be preferable.
    Tuesday, August 26, 2014 4:50 PM
  • Then using the script should work fine assuming you have the site's info properly published in AD.

    Note however that the client comes from the DP during a push install so if you're concerned about network usage that then your site design is probably sub-par and you will have the same issue during any software distribution or update deployment.

    Jason | http://blog.configmgrftw.com | @jasonsandys

    Tuesday, August 26, 2014 5:40 PM
  • Why using "find site" (which requires boundary/groups for site assignment)? You can also assign them to the new site(code) directly (using similar script logic).

    Torsten Meringer | http://www.mssccmfaq.de

    Tuesday, August 26, 2014 7:56 PM
  • Hmmm.  So a potentially unfortunate byproduct of moving servers from one site to another:  I had a maintenance window defined (2 hours on the weekend) in the source site, and an identical one defined in the target site.  During the migration it appears the maintenance windows from the source site are wiped and then those from the target site are added.  There's a transitional period where no user-defined maintenance windows exist and any pending reboots are allowed to proceed at will.

    And I have a question.  I've now defined a total of 2 maintenance windows (on 2 different collections of which servers are members).  However if I look at policyspy, I see 10 total.  What's that all about?  I read something about business hours (in Software Center?).  What effect to those have on restarts as a result of software update deployment?

    Wednesday, August 27, 2014 7:33 PM
  • Business hours are stored in the same way that maintenance windows are but have a different type attribute set. Business hours never allow anything to run and are used for something completely different so are not a factor in allowing anything.

    Jason | http://blog.configmgrftw.com | @jasonsandys

    Wednesday, August 27, 2014 7:47 PM
  • You can always run the report "Maintenance windows available to a specific client" to see what is available to the client (and it ignores business hours).

    Wally Mead

    Wednesday, September 3, 2014 3:04 AM
  • Thanks Wally.  However that report only shows me what's configured in the site database...it shows me 2 total maintenance windows.  It doesn't help explain why policyspy sees 10 on the client.
    Wednesday, September 3, 2014 4:00 PM
  • See Jason's reply (business hours)

    Torsten Meringer | http://www.mssccmfaq.de

    Wednesday, September 3, 2014 4:28 PM
  • So my best guess as to why the client shows 10 is this:

    7 are the "non-business hours" windows defined in Software Center (one for each day of the week)

    2 are the collection-based maintenance windows that I created

    1 is a "default" maintenance window that exists on all clients

    Does that sound about right?

    Wednesday, September 3, 2014 6:26 PM
  • Yep, sounds right.

    Jason | http://blog.configmgrftw.com | @jasonsandys

    Wednesday, September 3, 2014 7:25 PM
  • Yes, I understand. I was just stating that this report will always show you want is configured that the client has access to. I was not attempting to answer the others, as that had already been answered (business hours). I was just trying to give you a way to verify what maintenance windows the client should be aware of. Didn't mean to confuse you.

    Wally Mead

    Thursday, September 4, 2014 1:38 AM