Multiple SMS environments in same AD forest (Full Version)

All Forums >> [Management Products] >> Microsoft Systems Management Server >> SMS 2003



Message

mperry887 -> Multiple SMS environments in same AD forest (6/16/2008 9:51:26 AM)

Hey all...

I am currently in a battle at work and am hoping to get some help/ammunition from all of you. We currently have a SMS infrastructure set up with child servers for our desktop clients and other child servers for our Wintel servers. These all connect to one central SMS server. I REALLY want to leave this setup as is, as it is working quite well. The issue is that the server admins want full rights on the SMS console to do whatever they want on the server devices, so they want to build their own SMS environment for server devices only.
I am looking to gather all the information I can to say that this is not a good idea. I know a major issue is SMS boundaries, as the workstations and servers share the same AD subnets.

Could you please help me build a good case against bringing up a second SMS environment in the same AD forest?

Let me know if you require any additional information and I will fill in the blanks.

Thanks in advance



mreavis -> RE: Multiple SMS environments in same AD forest (6/16/2008 9:55:00 AM)

#1 concern is boundaries
#2 adding more complexity to the site is never a good thing
#3 if the server admins want full access, give them full rights to the All Servers Collection, and any other server collection they want.

Before I would build a site just for them, I would want them to define what they are wanting that they do not have now, and why.



mperry887 -> RE: Multiple SMS environments in same AD forest (6/16/2008 10:03:21 AM)

Thanks mreavis.

So my concerns with SMS boundaries are warranted? I would think that they would need to change all workstations and servers to different AD sites or subnets for this set up to work...is this correct?
The server admins want to be able to advertise SMS packages to server objects at anytime that they wish. We are very leary of giving out SMS Admin console rights to admins outside of our SMS Service Admin group (too many hands in the cookie jar and the fact that it uses SQL connections for each console connection). I did look into SMS Security rights for these server admins but it seems very hard to manage all these specific rights for this group.

Any other thoughts?

Thank you



mreavis -> RE: Multiple SMS environments in same AD forest (6/16/2008 10:13:10 AM)

yes, the only wany to ensure the site would work would be to move desktops and servers to a seperate subnet and AD site, otherwise you will have to manually install the clients on all computers in site, or use multiple GPOs.

I grant my desktop team ability to create packages, and advertise to a test collection, same for my software developers. Caveat to this is I do all production  deployments to ensure nothing goines out accidentally or to the wrong collection (then I would get the black eye).
My server team doesn't want that job, but it is just as easy. You can only hurt what you have access to, if that is only what you manage then you can only hurt yourself. Give them rights to create advertisements, see packages, and full rights (except modify) to their collections. Explain to them what will happen if they send a bad pacakge to their servers, have them sign a Memo of Understanding that they are responisble for what they do. If it is patching, then set them up for that as well. If they can only see the servers they will not damage anything else (I would exclude the SMS servers from their collections just in case [:D]). Ensure that management is aware of what they want, and whose is responsible for foul ups.  Much easier than building new sites, and restructuring your network.



mperry887 -> RE: Multiple SMS environments in same AD forest (6/16/2008 10:27:14 AM)

Looking at the SMS security rights available, we would need to give class rights on Advertisements and Packages and give instance rights on specific server collections...would this be the way to do it?

If I gave specific class rights on Advertisements and Packages, wouldn't that admin group have access to all advertisement and packages?

Thank you



mreavis -> RE: Multiple SMS environments in same AD forest (6/16/2008 11:05:37 AM)

That is correct, I would give them advertise and read to packages, and create and read to advertisements. On packages: you can grant them rights to only ones they would need at the instance level, but I think this would be a pain. Then just grant them rights to the  server collections, and maybe even be nice and see if they need any specific collections created for deployments.



mperry887 -> RE: Multiple SMS environments in same AD forest (6/16/2008 11:10:05 AM)

Ok...great...thank you for the information mreavis.

Is there any issues with too many SMS Admin console connections and the SMS DBs?

Thank you



jnelson993 -> RE: Multiple SMS environments in same AD forest (6/16/2008 11:55:49 AM)

For server management, we have the same kinds of issues where the server guys WANT a completely separate infrastructure because they think the desktop management folks are going to mess up and send a reboot job to all their critical servers (perhaps they're a little justified in being cautious).  But to have a completely separate hierarchy just for servers is unnecessary.   Aside from the issues mentioned, there's also the fact that any server inventory/patching data wouldn't rollup to one single repository with the desktop data.

You could do something like we're doing to put their minds at ease...have a site underneath your central primary that would be the administration site for all of their servers.  You could give them the appropriate permissions to the console items of that server and they'd be able to do what they needed to their servers.  Then you just remove the sender address from your central site so no site changes or software distributions can be replicated down to the servers' admin site, but all of the inventory, status, deletions, etc. from the servers can replicate up to your central admin site.  They get the safety of no desktop guys being able to reboot their servers, and you get the simplicity of one hierarchy and still have all of their data trickling up. 



mreavis -> RE: Multiple SMS environments in same AD forest (6/16/2008 11:58:56 AM)

depends on if you set a limit of console connections when you built SMS. We set oours for unlimited. As for performance, we have up to 20 consoles open and have not seen any issues.



mhudson -> RE: Multiple SMS environments in same AD forest (6/16/2008 12:08:02 PM)

Speaking from experience...We have an AD forest with 4 or 5 SMS/SCCM primary sites.  This is due to a decentralized IT structure.  So people have the ability to bring up a server in the AD forest when they want to with many Ad-sites in the forest.  Three times now I have found my server unhappy.  I was in shock when I saw only 3 computers had patched this month.  Looking through all the logs I found that the clients were talking to talk to a different MP.  As was the case before the boundary was set for the entire AD forest no just their AD site.  This as you can guess stopped every SMS/SCCM in the forest.



mperry887 -> RE: Multiple SMS environments in same AD forest (6/16/2008 12:42:38 PM)

quote:

ORIGINAL: jnelson993

You could do something like we're doing to put their minds at ease...have a site underneath your central primary that would be the administration site for all of their servers.  You could give them the appropriate permissions to the console items of that server and they'd be able to do what they needed to their servers.  Then you just remove the sender address from your central site so no site changes or software distributions can be replicated down to the servers' admin site, but all of the inventory, status, deletions, etc. from the servers can replicate up to your central admin site.  They get the safety of no desktop guys being able to reboot their servers, and you get the simplicity of one hierarchy and still have all of their data trickling up. 



This is an interesting setup for sure. I understand the concept and logic behind it but if server packages/advertisements are built at this child server will their status messages flow up to the Central server or will they only stay on that Child server?

Thank you



jnelson993 -> RE: Multiple SMS environments in same AD forest (6/16/2008 1:02:44 PM)

Well, a little of both.  The status messages themselves will trickle up if you have them configured to replicate in the Status Filter Rules in the site's Site Settings. However, that's just the status messages, the package and advertisement information won't trickle up.  So if you try to use the existing package/ad status reports/queries from the top you won't see anything.  Not because the status messages aren't there, but because the views/classes they join to don't have the corresponding packages/ads and thus show no records. 

The patch state information trickles up so you WILL be able to see vulnerability compliance but to see package/ad status you'll have to either run those reports from the child primary or create a linked server on your top admin site's SQL server to the child primary's SQL server and create queries that pull from there.



mperry887 -> RE: Multiple SMS environments in same AD forest (6/16/2008 1:51:30 PM)

quote:

ORIGINAL: jnelson993

Well, a little of both.  The status messages themselves will trickle up if you have them configured to replicate in the Status Filter Rules in the site's Site Settings. However, that's just the status messages, the package and advertisement information won't trickle up.  So if you try to use the existing package/ad status reports/queries from the top you won't see anything.  Not because the status messages aren't there, but because the views/classes they join to don't have the corresponding packages/ads and thus show no records. 

The patch state information trickles up so you WILL be able to see vulnerability compliance but to see package/ad status you'll have to either run those reports from the child primary or create a linked server on your top admin site's SQL server to the child primary's SQL server and create queries that pull from there.



Thanks John.

So from a reporting perspective, we would need to draw our reports from the Central site for workstation information and from the Child server for server information (advert/package status)?



jnelson993 -> RE: Multiple SMS environments in same AD forest (6/16/2008 2:04:13 PM)

Well, I guess I'd say it this way...for reporting, you can get all of your workstation information from the Central Site and for the server information you can get all but the advertisement/package data from the Central Site too (out of the box) and the ad/pkg data you'd have to get from the child site.

-or-

If you have a little SQL savvy, you can link to the child site and create some reports to pull server package/ad data from the child site and then you can get ALL of your data from the central site.  (see --> this article <--I wrote about getting data into web reports from databases outside your SMS db).  So if you had to absolutely have one spot for all information, you could...but I doubt that's the case for you guys or the discussion of having server guys with their own hierarchy would be over already :)

In practice, we pretty much get everything from our top reporting site for enterprise-wide reporting, but when the admins want to know server package status, they look at it from their own server.



mperry887 -> RE: Multiple SMS environments in same AD forest (6/16/2008 2:07:21 PM)

Thanks so much to all for the help.

It is time to go and fight the battle!



jnelson993 -> RE: Multiple SMS environments in same AD forest (6/16/2008 2:21:20 PM)

quote:

ORIGINAL: mreavis
I grant my desktop team ability to create packages, and advertise to a test collection, same for my software developers. Caveat to this is I do all production  deployments to ensure nothing goines out accidentally or to the wrong collection (then I would get the black eye).
My server team doesn't want that job, but it is just as easy. You can only hurt what you have access to, if that is only what you manage then you can only hurt yourself. Give them rights to create advertisements, see packages, and full rights (except modify) to their collections. Explain to them what will happen if they send a bad pacakge to their servers, have them sign a Memo of Understanding that they are responisble for what they do. If it is patching, then set them up for that as well. If they can only see the servers they will not damage anything else (I would exclude the SMS servers from their collections just in case [:D]). Ensure that management is aware of what they want, and whose is responsible for foul ups.  Much easier than building new sites, and restructuring your network.


Yeah, and it's funny too how SMS gets the bad rap when someone messes up.  We like to say that SMS/SCCM is just a catapult.  If you put crap on it and aim it at your office, the office will get hit with crap.  You can't blame the catapult for that, you gotta blame the guy that loaded it and aimed it.



mperry887 -> RE: Multiple SMS environments in same AD forest (6/16/2008 2:36:03 PM)

quote:

ORIGINAL: jnelson993

Yeah, and it's funny too how SMS gets the bad rap when someone messes up.  We like to say that SMS/SCCM is just a catapult.  If you put crap on it and aim it at your office, the office will get hit with crap.  You can't blame the catapult for that, you gotta blame the guy that loaded it and aimed it.



We actually use the train analogy for SMS/SCCM.



jnelson993 -> RE: Multiple SMS environments in same AD forest (6/16/2008 2:48:49 PM)

That works too.  One thing to mention, if you go the way of removing the sender address, keep in mind that the central site will continue to queue up replication traffic for the child server.  You just need to occasionally purge that stuff (SMS\Inboxes\replmgr.box\ready) perhaps with a scheduled task.  For us it amounts to like 1.5MB per month.



dem3tre -> RE: Multiple SMS environments in same AD forest (6/18/2008 5:36:55 AM)

This thread was really timely as we're kicking off our ConfigMgr implementation next week and I was seriously looking at building two seperate environments to protect the datacenters but not liking all the downsides that went with it. Then along comes John with another great post (love the blog btw) that solves my deliemma with minimal fuss.

quote:

ORIGINAL: jnelson993
You just need to occasionally purge that stuff (SMS\Inboxes\replmgr.box\ready) perhaps with a scheduled task. 


I'm not versed yet in all the message files that SMS/ConfigMgr moves around. How would you go about clearing that out so as not to affect your other sites downstream? Is it like the incoming and history folders where you have a file based on the site name?



jnelson993 -> RE: Multiple SMS environments in same AD forest (6/18/2008 10:26:00 AM)

Yes, there will be folders inside of that SMS\Inboxes\replmgr.box\ready folder that will have the site code appended like this
(if your site code for the Server Primary is XYZ)

SMS\Inboxes\replmgr.box\ready\1_11yc41.XYZ <-- Folder name, not file.  All repl data is inside that folder

So if you delete all folders named *.XYZ every once in a while then you'll get them.



Page: [1]

Valid CSS!




Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI
0.890625