We currently have SMS 2003 deployed throughout our enterprise and are in the planning phases of the SCCM 2007 implementation. We plan on performing a parallel installation of SCCM 2007 on new hardware while maintaining SMS 2003 during the transition. We have approximately 5000 remote clients (not located at headquarters) dispersed among 3x phyiscal locations (each connected to headquarters via WAN) and will manage the SCCM 2007 system centrally from headquarters. In addition to the increased functionality of SCCM 2007, we are also interested in integrating management of VPN systems, software update services and build in the capability to accommodate opreating system deployment in our SCCM 2007 implementation. What are the requirements for managing VPN devices? Can this be accomplished with a secondary server which is a child of the central primary server? All VPN clients come through headquarters When defining disk capacity requirements for the SQL server and central primary server...is there a recommended amount of disk space per client? Additionally, is there recommendations for array configurations (I've located supported cofigurations on line, but am interested in recommended disk sizing and disk configurations) Our planned hierarchy is listed below. Please take a look and let me know if you see any role conflicts or any other items that jump out at you. Server01 - located at headquarters - Central/Primary/Parent/Configuration Manager Console; SMS Provider computer; Component Server; Failback Status Point; Management Point; Reporting Point; Server Locator Point; ServerSQL - located at headquarters - SCCM Database server Server02 - located at headquarters - Secondary site - Distribution Point; Proxy Management Point; PXE Service Point; Software Update Point; State Migration Point Server03 - located at headquarters to manage VPN systems - Secondary site - ? Server04 through Server Server40 - located at each remote site (connected by WAN) - Secondary/Distribution Point; Proxy Management Point; PXE Service Point; Software Update Point; State Migration Point Looking forward to the additional information

Few things... 1. Why have a secondary site at the same physical location (HQ)? I can see why you might want a separate DP, but there's no reason to put a secondary site there, it just adds unnecessary complexity.2. The SQL DB from what I have seen is pretty small, but it also largely depends on what you collect. For example, in one of my positions we had two sites, one for servers, and one for desktops. The desktop site had approximately 2600 clients, and the DB was around 12-14GB, however the server site had about 10,000 clients, with a DB around 5-6GB. The reason for this was because on the desktop side there was a huge amount of software inventory data collected. Servers did not have this data collected and they were therefore a bare minimum of storage per entry. Best way to figure it out would be to look at your existing SMS database. The size of the DB isn't going to be significantly different between SMS and SCCM (assuming the software inventory is configured the same on both sites).3. The remote sites... what kind of WAN link are you looking at? ISDN, T1, etc, these slow speeds you may want to put a secondary site in, but anything faster and there's really no reason to put a secondary site in place there, just throw a DP out there and make it protected and you're done. Again, no reason to add unnecessary complexity if you have a reasonable connection. There's only going to be a relatively small amount of data transferring between client and MP anyway, the real traffic comes from the DP.4. I don't really have any direct experience with managing VPN systems using SCCM however, again, stay away from unnecessary complexity. I see no reason why a secondary site would be needed. This comes from the added knowledge that the SCCM client still needs to connect to the parent site in the heirarchy regardless of what site it is actually assigned too. (Meaning using the servers in the DMZ excuse is pretty much worthless as the FW will have to be opened up anyway).Scott Gill SCCM Consultant

Thank you Scott.1. Primary reasons I was proposing secondary site server at headquarters was to offload services from the central primary. After reading your post, I've removed the proxy management point role from the secondary site server at HQ. Now site roles for secondary site server at HQ will include Distribution Point; PXE Service Point; Software Update Point; State Migration Point. Thank you.2A. Good information. I previously reviewed our SQL database sizes for our SMS 2003 implementation and they are relatively small. I anticipate collecting similar data in SCCM 2007 as we have for the SMS 2003 implementation so will go with moderate increase in disk capacity for the SCCM 2007 implementation.2B. Any input on recommended disk array information for SQL server and central primary server will also be helpful.3. WAN connections - partial T/full T/Multiple T's - completely agree with distribution points at the remote sites (our SMS 2003 implementation is configured this way). One of our goals for remote sites is to put the necessary infrastructure in place to support operating system deployments, software update services and support state migration. With that in mind, is it unreasonable to configure secondary site servers at remote locations?4. Managing systems coming in through our VPN (Juniper) solution is high on our list of needs. If anybody can provide any guidance on this, I'm interested in hearing the details of your specific configuration

1. You're welcome. Additionally, there really isn't much of a reason to deploy multiple SUP's either. The SUP is simply where all the synchronization occurs, when machines go to actually install patches they download them from the local DP just like a regular package.2B. I'd say this is probably a matter of opinion. While personally I wouldn't go below a 15k drive for this, the number of drives in the array is totally up to you, and considering you probably won't have a DB that's much over 10-15G I see no reason why several spindles would be needed. I'd recommend 2 for RAID 1, and I'd probably want the DB to be on a separate chain from the OS (2 drives for the OS, 2 for the DB -- if you have the budget for it, otherwise 2 should be fine).3. Yes I would say it's unreasonable. All of these services can be offered without deploying secondary sites (just install the DP, PXE SP, SUP [although note my comment in #1 about the SUP], and SMP roles and then you can do all of this at the remote sites). Additionally, you'd be lowering cost by doing this as there would be no need to purchase additional licenses.4. What exactly are you looking to manage as far as VPN is concerned through SCCM? I don't think you can really do much with SCCM without some kind of third party add-on. Unless you're just talking about the clients that are VPNing in through your VPN infrastructure? In which case, that's exactly the same as managing a client on the LAN, except slower. Two things you'll need to check on for this: A. VPN IP's (or AD site of VPN clients) need to be added to the site boundaries. B. You'll need to make sure that the MP and at least one of your DP's is unprotected (or protected with VPN boundary information as part of the protected boundary). Other than that managing clients over VPN is exactly the same.Scott Gill SCCM Consultant

Agree with Scott. VPN clients can be managed as clients connecting to the local LAN. I think you could allocate a separate IP address range to VPN clients connecting to the HQ. Then add this address range as a separate subnet boundary, and mark it as "Slow or unreliable". When creating the advertisement for the package, you can choose if you want to distribute it to the clients found in this boundary (see the "When a client is connected within a slow or unreliable network boundary" setting). If your VPN clients visit the HQ regularly, it is a viable option that you do not distribute software over the VPN connection; clients receive packages when they are in the office. Also, you can create a separate site in Active Directory, and assign the VPN clients' IP range to this site. Then add the site as a boundary to SCCM. This makes easier to manage subnets and sites, because you can do ever administration in AD sites and services. If your VPN clients never visit the HQ, the question is more difficult. In this case, you could use BITS to limit bandwith usage, so they will receive software packages, and will still be able to use their Internet connection, during the download. If the have a frequently-used Internet connection, but do not have a constant VPN connection, then Internet-based management can be useful for you too.mz

3. It's my understanding that there are no license fees associated with SCCM 2007 secondary sites. If I have the available hardware, I would think it would be beneficial to leverage secondary site capabilities? Primarily, I'm interested in managing network bandwidth utilization. Many of our business applications are centralized at headquarters. The more efficiently we can manage utilization by SCCM, the more available bandwidth available for our critical business applications.4. We have quite a few remote only employees that connect through VPN. The primary objective is to collect asset management information for the remote systems. No problem with adding the subnets to the boundaries. We'll have to test to verify we can communicate with the remote systems. We were not able to in SMS 2003 (not sure if it was a limitation with 2003 or ACL issue)Thank you Scott.

3. Ok I have never setup a secondary site, came close once but I wasn't sure about the licensing. Anyway it still adds a level of complexity that shouldn't really be necessary. If bandwidth is all you're worried about you can do it this way, or you can also limit bandwidth with BITS... either way should work just as well. The main difference is that communication from clients is funneled through a "proxy" instead of connecting to the primary MP. Bandwidth isn't really "saved" it's just redirected and in some cases limited, both of which can be done with inventory rules and BITS.4. I'd start by looking at your ACLs. SMS 2003 was able to manage clients through VPN the same way SCCM can (as long as the boundaries were setup correctly). There are several ports that need to be opened up for "Full" support, but only 80 should be needed for standard management.See:http://social.technet.microsoft.com/Forums/en/configmgrgeneral/thread/953295c2-bca2-406f-85a2-f114bae19af8http://technet.microsoft.com/en-us/library/bb632618.aspxScott Gill SCCM Consultant

3. It's my understanding that there are no license fees associated with SCCM 2007 secondary sites. If I have the available hardware, I would think it would be beneficial to leverage secondary site capabilities? Primarily, I'm interested in managing network bandwidth utilization. Many of our business applications are centralized at headquarters. The more efficiently we can manage utilization by SCCM, the more available bandwidth available for our critical business applications.Correct no additional license costs for a Secondary, and in my opinion if you really need to control bandwith a secondary is the best way to do it in my opinion, allthough with Win7 and peer caching I see other alternatives. But as Scott says it brings some additional management on top.

Thank you all for your input.

You are welcome, I wish you a Happy New Year from Sweden tomorrow.