locked
SCCM 2012 Secondary Site RRS feed

  • Question

  • I'm trying to figure out the purpose of having a Secondary Site when using Config Manager 2012. Can you please give an example when/why I would need one.

    I'm planning to have my Primary Site here in Virginia but I also have approx 30 computers in Canada. I have a 3 Mbps WAN connection to Canada. I don't want the Canada computers to go all the way here to get updates, etc. so I will install a Management Point and Distribution Point server in Canada. Will this be enough to manage all the computers there or will I need a Secondary Site?

    Thank you in Advance for your help.

    Monday, March 18, 2013 7:07 PM

Answers

  • Reports from the console just take longer to load when remote -- it has nothing to do with being in a secondary site because consoles have nothing to do with secondary sites.

    Are you expanding the Reports node and selecting individual categories or are you directly selecting the reports node? If directly selecting the reports node, it always takes longer to enumerate; try expanding the node first and then selecting just the sub-category. If that still doesn't help, try using the reports directly from the SSRS web site instead of using the console to access them. Assuming that you Reporting point is installed on your primary site server and with the default instance, just point your browser to http://siteservername/reports.


    Jason | http://blog.configmgrftw.com

    • Marked as answer by Emil Antonio Tuesday, July 9, 2013 3:32 PM
    Tuesday, July 9, 2013 2:09 PM
  • All console traffic goes over the WAN -- as mentioned, the console connects to the primary site server (more specifically, it connects to the SMS Provider in the primary site which is probably on your primary site server). There is no choice, as mentioned, that's how it works. How else would it be able to manage the site if it didn't connect over the WAN? If you are concerned about this traffic, you should monitor it at a network level to see if it is impactful (or not)? If it is, then you can consider using a Remote Session host or VDI solution physically closer to your primary site server to run the console and allow the remote admins to connect using RDP or ICA.

    Remote Tools is not part of the console; notice that it launches a separate program. Initially remote tools does connect to the primary site to verify permissions and record a status message (if it's launched from the console), but then it's a direct connection to the system being controlled.


    Jason | http://blog.configmgrftw.com

    • Marked as answer by Emil Antonio Tuesday, July 9, 2013 3:32 PM
    Tuesday, July 9, 2013 2:53 PM
  • I would recommend starting with a remote DP. This should suffice for only 30 clients. Management point's aren't assigned to clients by location so if you install a MP in Canada clients won't neccessary get assigned to that MP (You would need to install a secondary site in Canada to force clients to use that MP). For 30 clients the communication between the client and the MP (In Virginia) shouldn't be that bad.

    See these post for some more info to help choose between DP and Secondary Site:

    http://social.technet.microsoft.com/Forums/en-US/configmanagergeneral/thread/e79e3f4d-0518-467c-8d7f-81cbb964b6c7

    http://social.technet.microsoft.com/Forums/en-US/configmanagerdeployment/thread/54d1bad7-d511-4861-ad04-b0d803482479/

    http://social.technet.microsoft.com/Forums/en-US/configmgrgeneral/thread/b4cd7783-00e0-4a2c-9312-1671ce7dd9cc/#d784e1c5-8b50-4cf0-b01c-2c07743d9771


    Justin Chalfant | Blog: setupconfigmgr.com | SCUP Catalog: patchmypc.net/scup | Please mark as helpful/answer if this resolved your issue


    Monday, March 18, 2013 7:16 PM

All replies

  • I would recommend starting with a remote DP. This should suffice for only 30 clients. Management point's aren't assigned to clients by location so if you install a MP in Canada clients won't neccessary get assigned to that MP (You would need to install a secondary site in Canada to force clients to use that MP). For 30 clients the communication between the client and the MP (In Virginia) shouldn't be that bad.

    See these post for some more info to help choose between DP and Secondary Site:

    http://social.technet.microsoft.com/Forums/en-US/configmanagergeneral/thread/e79e3f4d-0518-467c-8d7f-81cbb964b6c7

    http://social.technet.microsoft.com/Forums/en-US/configmanagerdeployment/thread/54d1bad7-d511-4861-ad04-b0d803482479/

    http://social.technet.microsoft.com/Forums/en-US/configmgrgeneral/thread/b4cd7783-00e0-4a2c-9312-1671ce7dd9cc/#d784e1c5-8b50-4cf0-b01c-2c07743d9771


    Justin Chalfant | Blog: setupconfigmgr.com | SCUP Catalog: patchmypc.net/scup | Please mark as helpful/answer if this resolved your issue


    Monday, March 18, 2013 7:16 PM
  • Justin,

    Just a follow up questing about Secondary Site.

    I setup a Secondary Site in Canada and everything seems to be working. I was able to deploy SCCM agent from the console and deploy packages to computers in Canada.

    The issue now is when I open the SCCM Console from the Secondary Site server (connecting to Primary Site), the Reports tab is taking a long time to load (approx 30 min). I want my Canada admins to manage the Canada site only. My question is where should they connect when launching the SCCM Console? Primary or Secondary site? Should I give them RDP access to the Primary Site server and manage the Canada site from here? Ideally, I want them to install the SCCM console from their computer in Canada and connect to Primary Site. Please let me know what is the best practice on managing Secondary Site. Thank you for you help.

    Tuesday, July 9, 2013 1:15 PM
  • First, why did you install the console on the secondary site server (I'm actually surprised it let you). You can install the console on their (or any) workstations.

    Next, secondary sites have *nothing* to do with administrative delegation -- that's what role based administration (RBA) is for: http://blogs.technet.com/b/configmgrteam/archive/2011/09/23/introducing-role-based-administration-in-system-center-2012-configuration-manager.aspx

    Finally, consoles *never* connect to secondary sites.

    Secondary sites are purely about moving certain roles (specifically the MP and SUP) closer to the clients so that they don't have to traverse the WAN for policy or the update catalog or to submit inventory as well as state and status messages to the primary site.


    Jason | http://blog.configmgrftw.com

    Tuesday, July 9, 2013 1:32 PM
  • Jason,

    Thank you for the reply. From my understanding everything is managed in the Primary Site and my remote Admin users should connect their consoles to the Primary Site. Do you know why it takes a very long time to load the Reports tab? I dont have this issue when I launch console from my computer located in the Primary Site. Is there a log I can check to help troubleshoot this?

    Thank you.

    Tuesday, July 9, 2013 1:53 PM
  • Reports from the console just take longer to load when remote -- it has nothing to do with being in a secondary site because consoles have nothing to do with secondary sites.

    Are you expanding the Reports node and selecting individual categories or are you directly selecting the reports node? If directly selecting the reports node, it always takes longer to enumerate; try expanding the node first and then selecting just the sub-category. If that still doesn't help, try using the reports directly from the SSRS web site instead of using the console to access them. Assuming that you Reporting point is installed on your primary site server and with the default instance, just point your browser to http://siteservername/reports.


    Jason | http://blog.configmgrftw.com

    • Marked as answer by Emil Antonio Tuesday, July 9, 2013 3:32 PM
    Tuesday, July 9, 2013 2:09 PM
  • Jason,

    What kind of traffic go over the WAN when my remote admins connect to the SCCM console to the Primary Site Server?

    For example, if they use Remote Tools and try to connect to a computer in Canada, does the command comes from the Primary Site server (over the WAN) and then comes back to Canada to connect to the remote computer?

    Tuesday, July 9, 2013 2:12 PM
  • All console traffic goes over the WAN -- as mentioned, the console connects to the primary site server (more specifically, it connects to the SMS Provider in the primary site which is probably on your primary site server). There is no choice, as mentioned, that's how it works. How else would it be able to manage the site if it didn't connect over the WAN? If you are concerned about this traffic, you should monitor it at a network level to see if it is impactful (or not)? If it is, then you can consider using a Remote Session host or VDI solution physically closer to your primary site server to run the console and allow the remote admins to connect using RDP or ICA.

    Remote Tools is not part of the console; notice that it launches a separate program. Initially remote tools does connect to the primary site to verify permissions and record a status message (if it's launched from the console), but then it's a direct connection to the system being controlled.


    Jason | http://blog.configmgrftw.com

    • Marked as answer by Emil Antonio Tuesday, July 9, 2013 3:32 PM
    Tuesday, July 9, 2013 2:53 PM
  • Jason,

    "Reports from the console just take longer to load when remote".... What is the typical response time when accessing the console from a remote location? I have a 4 Mbps WAN connection to my remote site and my admin is reporting it takes about 5 min to load a report. Is this normal?
    Is it typical to use some kind of Remote Host session that is hosted near the Primary SCCM Server for remote admins when using SCCM console?

    Thank you.
    Wednesday, July 10, 2013 5:47 PM
  • There is no "normal" -- your environment and its response times over the WAN are specific to the details of your environment (and expectations).

    Yes, it is a common solution to use a remote session host located physical closer to the SMS Provider and site server.

    Did you try running the reports from the SSRS web site instead of the console?


    Jason | http://blog.configmgrftw.com

    Wednesday, July 10, 2013 7:20 PM