.Net3.5 and Server 2012

I have tried several ways to get the .Net Framework 3.5 in stalled on Server 2012 however the only way that ever works every time and is supper fast is powershell.
 On the Server 2012 media is a folder called sources\sxs so from an elevated command window I run
dism /online /enable-feature /feature:netfx3 /all /limitaccess /source:f:\sources\sxs as per the screenshot below. F:\SOURCES\SXS is just whereever you have the SXS folder located.

Now I was working on a project with installs around the world and it was proving hard to get the media to all the different sites and I was wondering if copying just the .net3.5 cabs from that SXS folder would do the job as its only 18Mb but alas it didn't work and I had to go back to the full folder.  What I now do is to load the SXS on a network share and just use the network path in a powershell script.

SQL Permissions Error on setup (The SQL service account login and password is not valid)

I was installing several SQL instances for a SCCM pre-prod environment that was going to mimic a production build but on a much smaller basis.  I was using a specific AD account and it had to span 3 domains in the same forest.  In the first domain (where the account existed) I had no issues. Once I went to the other 2 domains I kept getting the same 2 errors, namely

"The SQL Server service account login or password is not valid"
Or
"The credentials you provided for the Reporting Service are invalid"

I make as many mistakes as the next so I wrote down the username and password on notepad and then opened power shell as that user (so I deffo knew I was using the correct username and password)

I am crap at reading past error messages but the second error caught my eye

So it is telling me here that if I have an issue with the domain account I can go and change that in SQL Configuration Manager.  So I can perform my install with the standard built-in accounts and then change it when the install is done.  But the really important thing here is that  you can't go to services.msc and change the account that any of the SQL services run under as this will not allow SQL to properly configure the services.  One of the things that the SQL configuration does is grant the user the right to logon as a service. (that might have been my issue but it still does not make sense when SQL configuration manager can make the changes)

When you jump onto SQL Configuration services and select the SQL services and change the user account from the built in account to the domain account you want.

Now you can see that I have all the services changed to domain accounts, except for the Reporting Service

 To change the SSRS you need to logon to the SSRS Configuration Manager, before we can change the account to a domain account we need to backup the encryption key.

Now when I look at the SSRS page there is a domain account and not a built in account

And the same can be seen on the SQL configuration manager page 

 There are 2 last points here, if you are installing SCCM you must use network accounts you cannot use the build in SQL accounts and if you are running these services under a domain account then you will need to register the SPN.

To CAS or not to CAS....

I have been designing and deploying configuration manager for 12 years. In recent years I have been lucky enough to be working on some large scale SCCM projects.  So what is large scale to me? over 40,000 seats goes into the "large scale" category for me.  The CAS is nothing new to SCCM in 2007 we had the idea of the central admin site and in many ways it acted in the same way as the CAS. The CAS or Central Admin Server is basically a central admin location where you can manager multiple primary sites in one console.

When SCCM 2012 was released the CAS had to be installed during the initial install phase and as a result a lot of people deployed a CAS as a just in case design.  The CAS then received a lot of negative press because it implemented a layer of complexity that many didn't understand.  I am going to cover the physical things to do when deploying a CAS in another blog but in this blog we are just going to look at some of the design decisions you may go through when choosing to deploy a CAS.

A single Primary Site (PS) can support up to 100k clients and I have never deployed a SCCM environment with 100k seats but have installed a CAS 3 times so was I wrong to do that?  So let me give you a profile of 1 install.  The customer was a retail customer with a total of about 80k seats.  The client was expecting about 5% growth over the next 3 years and they have a support goal of never going past 80% of the Microsoft supportable limit and so we needed a CAS to support more than 1 PS.

My next install was for 45k and that is well within the 100k limit with a growth rate of about 15% over the next 3 years, with this deployment we still went for a CAS and 3 PS servers.  So if the CAS includes more complexity and more databases and servers then why chose a CAS?

It came down to the following points;

If I have a single PS server supporting say 50k clients and it goes down then we can add no new software, clients or OS images.  No new policies can sent to the clients and this means its a pretty high single point of failure for a large org.

In this example we have 1 CAS and 3 PS, the 3 PS were in the US, EU and APAC.  With this design we could loose the CAS and 2 PS servers and still have no issues with the last PS working.

There is no doubt that with the changes to SCCM SP1 and the ability to add a CAS after installing the first PS that for smaller sites its going to be more likely that more smaller sites will not go for a CAS to begin with unless you really need one, and who should decide that ... well you.

In SP1 there are also some good changes to how we can view what is happening from a site replication standpoint from within the monitoring component.