Jump to content


jeaostro

System Center hierarchy solution

Recommended Posts

Hello

 

I love this site, a lot of very good guides that have helped me a lot!! :) But now i need help with more "advanced" installations.

 

Are there any good guides(best practices) for setting up a SCCM(config manager) solution with a central site, different primary sites, and under each primary site secondary sites?

 

We have a project where we would like to set up a central site(Primary) in the main office in Norway. Then have "primary child sites" for the other larger offices in Sweden, Denmark and so on. In Sweden, Denmark and Norway we also need "Secondary sites" under the primary sites because we have smaller offices in different parts of Denmark, Sweden and Norway. We need OS deployment, Software Deployment, Inventoy, Asset management, Virtual application streamin, WSUS and so on.

 

Is this the best solution? Central/Primary/secondary as i described above?. A total of computers in the whole company is about 10 000. And we also need to be able to deploy about 800 computes in the night so they can be ready for the next work day.

 

Some of the primary sites will be administered by local IT persons, but we also need to be able to manage all the sites from the central site.

 

Thanks for the answers :)

Share this post


Link to post
Share on other sites

Hi Jaeostro,

i didn't really find any guides like this however my company is a MS Strategic Alliance partner globally and as such i did a design and asked them to check it out for me. i will give you a basic run down of our projects of our scalable design... easily modified from 10k to 250k

 

 

the design covered:

1 Forrest

1 Root domain (internal.dns)

6 regional domains (apc.internal.dns)

COUNTRY OU's (best suited our administrative processes)

 

1 Central Site for reporting (RPT)

6 Central sites for the global regions reporting to RPT (APC, USA, AME, EUR, SAM, PAC)

 

then each regions central site had country base primary servers (AU1) reporting to regional

then Locational Primary servers, then for sites we had Secondaries and Branch where required..

 

EXCEPTIONALLY COMPLEX and took maybe 3months to do basic design and validation prior to submitting.

This system had to support 200K Users globally. We also included APP-V, WSUS, OSD, ETC and also OCS r2.

 

 

Your basic design looks sounds.... just flesh it out in a workspace before commiting to early....

 

Is this the best solution? Central/Primary/secondary as i described above?. A total of computers in the whole company is about 10 000. And we also need to be able to deploy about 800 computes in the night so they can be ready for the next work day.

When you plan this make sure you put alot of thoughts into the system roles and your network capabilities. The design work can be reasonably quickly whipped out however doing your validation and bandwidth allocations in relation to WSUS(SUP) and APPV Streaming can be a nightmare.

 

From the Project management / Problem resolution side: Don't be too greedy or ambitious with your OSD overnighters. We found that 200 a night was a good number for us to deploy with a team of 2 onsite staffers (1 over night onsite, 1 early starter and fault fixer)

 

Some of the primary sites will be administered by local IT persons, but we also need to be able to manage all the sites from the central site. We had the same requirement however this is difficult to achieve with the security side... permissions become quite convoluted after a while. Highly recommend putting serious thought into how you will administer this...this becomes a nightmare in large deployments. Also contemplate building an APPV package of the SCCM Console

 

 

just some basic thoughts, feel free to throw me some questions if you need to... if you get stuck with your design let me know and maybe i can extract some design information from one of our designs that may be able to suit your requirements...

 

 

enjoy....

 

Jammy

Share this post


Link to post
Share on other sites

thanks for a great response! :)

 

The first step in the project this year will be to set up a central site in the main office in Norway, and set up on primary site for another office in Norway.

Create the packages and OS on the central site, and distribute them to the other primary site in Norway.

 

But another question. What about disaster recovery? Is it possible to set up two "central site servers"? I mean that we have the central site on a server, and if this server stops working, we can switch to the other "central site server" that is on another server? The second server needs to be in the same "state" as the first one, so this one can take the "role" of the one that stopped working. Or is there another solution for "mirroring" the SCCM central site server? Or some other good disaster recovery solution?

 

Also what about if the customer has more than one wsus server? Can SCCM control many WSUS servers?

Like if they have one wsus server in the main office in Norway that is controlled by the central site, but also another wsus server on the primary server in Denmark that is controlled by the primary sites in Denmark?

Can we control all the wsus servers from the central site, but the local admins in Denmark can also control the wsus server connected to their primary sites and distribute updates? Or should all updates be pushed from the central site only?

 

A loot of questions here :) I'm trying to look for good answers on technet, but there is so much information :(

Share this post


Link to post
Share on other sites

thanks for a great response! :)

 

The first step in the project this year will be to set up a central site in the main office in Norway, and set up on primary site for another office in Norway.

Create the packages and OS on the central site, and distribute them to the other primary site in Norway.

 

But another question. What about disaster recovery? Is it possible to set up two "central site servers"? I mean that we have the central site on a server, and if this server stops working, we can switch to the other "central site server" that is on another server? The second server needs to be in the same "state" as the first one, so this one can take the "role" of the one that stopped working. Or is there another solution for "mirroring" the SCCM central site server? Or some other good disaster recovery solution? We actually just use Doubletake (http://www.doubletake.com/) solve this issue as we ran into the same issue. Please note we have only actually used this solution once and then it took around 3 hours to restore to operation. We have a DR Test scheduled in October to test this solution again

 

Also what about if the customer has more than one wsus server? Can SCCM control many WSUS servers?

Like if they have one wsus server in the main office in Norway that is controlled by the central site, but also another wsus server on the primary server in Denmark that is controlled by the primary sites in Denmark?

Can we control all the wsus servers from the central site, but the local admins in Denmark can also control the wsus server connected to their primary sites and distribute updates? Or should all updates be pushed from the central site only? Yes my understanding is that it can, however the complexity of this would to me make it simply not worth the effort, multiple rules and procedures for patch approval etc. We have always built a consolidated model and as such have built a new WSUS network to suit. Generally we put our SUP front ends at any site with 50+ PC's, in one case we have built country-by-country wsus environments due to software compatability ... no ie7 because of seible compatability etc.

 

A loot of questions here :) I'm trying to look for good answers on technet, but there is so much information :(

 

 

Anyweb may be able to fill in more on the WSUS/SUP side of things, i believe he would have more knowledge on SUP.

 

 

Enjoy :-)

Share this post


Link to post
Share on other sites

Just read this on Technet: "There can be multiple site system servers with the software update point site system role, but only one site system server can be configured as the active software update point."

 

Does this mean that we can have a WSUS server in Norway(primary site), and a WSUS server in Denmark(primary site), then have Software update point site system role on the server in Denmark and Norway, but only one of them can be the Active one? For example the one in Norway, then from the active point in Norway you need to deploy updates to Norway and also Denmark?

 

Cant the Primary site in Denmark have its on WSUS server and its own active software update point? That they can administer themselves, but we can also manage it from the Central site?

 

Is the above limited to when you have only one WSUS server for Norway and Denmark, but two Software update point (one in denmark and in norway)?

 

Best regards.

Jean André

Share this post


Link to post
Share on other sites

The documentation is kinda confusing on that part, but there can be multiple Active Software Update Points. Active in this case means that clients can use it for scanning etc. See also this discussion on the Technet Forum: http://social.technet.microsoft.com/Forums/en-US/configmgrsum/thread/102f653d-fcc2-41cf-bd8c-cc074de879f7

Share this post


Link to post
Share on other sites

Thanks for the response, got a better understanding now :) But is it also possible to have more than one wsus server?

If they have one WSUS server in denmark(primary site) and a SUP that downloads updates from this local WSUS server.

Then also have a WSUS server in the Central Site in Norway and a SUP here.

 

For the most the IT people in Denmark will administer their own SUP and WSUS server, but we need to be able to control the SUP in Denmark from the Central Site in Norway. An example is if the local admin in Denmark is sick, and we need to push critical updates to the clients in Denmark. Is this possible, or is it a bad solution?

 

Is the best solution to have one WSUS server and SUP in the central sites, and a SUP in Denmark that downloads updates from the SUP in Norway?

Share this post


Link to post
Share on other sites

Hi Jeaostro,

That is generally how it is done in my experience. We found that trying to build the "lets call it duplicated redundancy" into each individual region we were far better of modifying our business processes to allow this kind of contingency. Given you can assign "fairly" granular controls over activities in SCCM this was easier than trying to resolve these issues on a grand scale. noting however that we had absolute governance over the entire environment so wasn't really an issue.

 

We generally put our primary in the central administrative site and push out to SUP's, also note that reporting in this method needs to be built to return results to the reporting site.

 

Will have a look through doco again and brush up see if we can't help a bit more on the tech side.

 

Jammy

Share this post


Link to post
Share on other sites

Hello and thanks for the response and effort :)

 

My hair is getting gray after reading threw Technet on Software Update points.

What i need is a "best practice recommendation" for the case described above.

 

Should we have one WSUS server and a Software update point on the Central Primary Site in Norway that we administer ourselves. And also have a WSUS server and Software update point in Denmark, which the IT people in Denmark administer by themselves. Can we also administer this SUP from the Central Site in Norway?

 

 

Best regards

Jean André

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...


×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.