Hi Guys,

We are looking to consolidate our SCCM 2012 R2 standalone site into AWS. I am just in the planning stage but was wondering if there is any possibility i can build a new server/SQL in the cloud and migrate the roles across or is it best to do a backup and restore? I know this is probably not supported but am open to any options that will make this as easy as possible.

If you think the above is too troublesome or not possible, i am open to a VM migration as a last resort but currently the DB server and PS server are separated and i would like to bring them into the one VM. If you could advise on that process i can see if i can make it work.

thanks in advance!

cheers

ben

• Edited by Ben Parkes Wednesday, July 22, 2015 2:04 AM clarity

"build a new server/SQL in the cloud and migrate the roles across"

Building a new site server means building a new site and roles cannot be "migrated" between sites. The only possibility here is to actually move the OS instance hosting the site server itself or perform the backup and restore.

Do you have a back-end VPN set up from your network to AWS and is IP traffic un-impeded? If not, you will run into loads of issues hosting your site in AWS. Also, this won't be supported by Microsoft at all.

Thanks for the response! I am lucky enough to be leveraging off my production environment (we are a SaaS company) so interconnectivity shouldn't be an issue.

To reduce the load on traffic from workstations, my plan was to have servers in each office have the following roles: Application Catalogue, Distribution Point and Management Point while having a Powershell script export all prestaged content to a drive which is then replicated to servers with a robocopy or some other sync process in off hours.

We were hoping to save cost by turning the SCCM server off over weekends etc, is it recommended to have it always on? I only ask as this would almost be the same as having connectivity issues.

Why would you use robocopy instead of the built in content sender? It's is perfectly capable of scheduling and throttling content transfer to DPs.

Having the app catalog on the remote site systems (remote from the site server) provides very little benefit. The app catalog is just a web service and web site -- no content is actually delivered from it.

You'll need SUPs at the remote site systems also to do software updates.

No, I would never shut off a production site server.

We will be using scheduling and throttling on DP's in Asia as they will have fast links to the Site Server AWS instance but as we are consolidating ASIA and EMEA into one site and trying to keep costs down we will be using AWS buckets to replicate the data at high speed across the globe.

I am a bit confused in regaurds to the SUP role, i thought there was only need for SUP 1 role in the site (for SCCM to connect and download from) if i am deploying software update deployment packages via automatic deployment rules

"i thought there was only need for SUP 1 role in the site (for SCCM to connect and download from) if i am deploying software update deployment packages via automatic deployment rules"

Not correct.

First, update/deployment packages are not deployed in any way, software update groups (or individual updates) are -- these are two different objects.

Next, while yes you technically only need one SUP to enable Software Updates, the SUP, really the underlying WSUS instance on the SUP, is responsible for making the Windows Update catalog available to the Windows Update Agent on the clients. The catalog varies in size and the catalog download by the WUA is a delta on a month to month basis but there are times when a full download happens (like the first time the catalog is downloaded of course). The full catalog will be in the 10-20MB range (or more) depending upon the products, languages, and classifications that you choose.

Also note that SUP (once again really WSUS) selection by the clients can't be directly controlled. Clients choose SUPs based upon domain and forest and then at random. This is similar to MP selection (although as of R2 CU3 you can hard-code available MPs on a client and as of R2 SP1 you can use boundaries to define MP affinity). This is completely different from DP selection however which is always based upon boundary groups. 

thanks again for the information!