In preparation for your upgrade to SCSM 2012, you will want to set up a Pre-Production environment to test the upgrade in first. You will want to make sure that the upgrade goes smoothly and that your customizations are preserved as expected. Doing so will ensure a smoother production upgrade. Customers often ask us how to replicate their production environment as a pre-production environment.
Here is how we worked with one customer – Fletcher Kelly (@fskelly) – to do it.
1. Promote a new DC into Production, wait for replication.
2. Add a admin account to Schema Admins (this is needed later on)
3. Do not reset any passwords of any run as accounts (learned this one the hard way)
4. Move DC into ring-fenced network.
5. Seize all required roles to the “Lab DC” (ntdsutil, this is where the Schema admin is needed for Schema Master)
6. Restored a DPM backup of the SM management sever VHD and DW management server VHD
7. Restored the required databases for SM (serviceManager LDF and MDF)
8. Restored the required databases for the DW (DWDataMart, DWStagingAndConfig and DWRepository)
9. Create the required Virtual Machines using the vhd’s you restored.
10. Present additional VHDs to replicate production drives. Each of the servers had two additional drives for MDF and LDF files respectively.
11. Copy the required MDF and LDF to the necessary locations on both the MS and the DW.
12. Restart both MS and DW
13. Once restarted, check the System Center Data Access Service, System Center Management and System Center Management Configuration Services
14. Check for a warning regarding SPN in the event log stating that a SPN must be created.
a. Log onto the server complaining about SPN (Usually MS and DW) b. Run the following command (without quotes)
a. Log onto the server complaining about SPN (Usually MS and DW)
b. Run the following command (without quotes)
i. “setspn –U domain\username –A MSOMSdksvc/netbiosnameofMS” ii. “setspn –U domain\username –A MSOMSdksvc/FQDNofMS” iii. “setspn –U domain\username –A MSOMSdksvc/netbiosnameofDW” iv. “setspn –U domain\username –A MSOMSdksvc/FQDNofMS”
i. “setspn –U domain\username –A MSOMSdksvc/netbiosnameofMS”
ii. “setspn –U domain\username –A MSOMSdksvc/FQDNofMS”
iii. “setspn –U domain\username –A MSOMSdksvc/netbiosnameofDW”
iv. “setspn –U domain\username –A MSOMSdksvc/FQDNofMS”
For example mine – “setspn –U <some domain>\MySMSystemAcct -A MSOMSdksvc/MySMServer
For example mine – “setspn –U <some domain>\MySMSystemAcct -A MSOMSdksvc/MySMServer.mycomoany.com
15. If you got the error mentioned above, restart System Center Data Access Service, System Center Management and System Center Management Configuration Services
Some other ideas I have but which I haven't tested yet:
1) Instead of introducing a new DC, try to P2V one of your DCs.
2) Instead of using a ring fenced physical network, put all your VMs on a private network on a host.
3) If your SM servers are installed physically try to P2V them.
Let me know how it goes for you in the comments below and we can all learn from each others experiences.
Not tried it yet in a Hyper-V environment, but in an ESX environment, simply cloning the VM's (DC, SM, DW, SQL) and changing the NIC's so they're on an isolated virtual switch works really well.
If you have SCVMM, I can't see it being any different, except maybe the network would need some tweaking with VLAN tagging etc to isolate it a bit more.
Thanks for posting this for me.
I will try to assist with questions here as well.
I tried to do something similar, I made VHDs from my DW, SM and DC servers with disk2vhd, I couldn't do this on the SQL server because of a EFI System partion, so I built a new SQL server for the testing. I set these up in VirtualBox and I have them communicating fine there.
But when trying to launch the SCSM Console it fails with:
Failed to connect to server 'smserver.domain.local'
The Data Access service is either not running or not yet initialized.
in the SM server I got the Data Access Service terminated unexpectedly on every attempt to launch the console, on the SQL server I got a corresponding security log audit success event that the SCSM service account I use is logged off, so the communication there, but something else is wrong.
I've redone the SPN records.
Originally I was using SQL Express, but when I remembered SCSM requires full SQL I reinstalled that (trial).
the SCSM service account is SA in SQL and local admin windows group on the SQL server.
Check the Operations Manager event log on the SCSM server for information on why the Data Access Service wont start.
Did you give the SQL the same server name and instance name as your original / prod environment?
Yes, SQL server has the same hostname and SQL instance name.
In the Ops Mgr Event log,
1. OpsMgr SDK Service: The System Center Data Access service has started.
2. Lfx Service: Starting Lfx sub service
3. OpsMgr SDK Service: The System Center Data Access service has reestablished database connectivity.
4. Lfx Service: StartMonitoring: started originally:False
5. (Warning) Lfx Service: Errir starting Lfx service. Tried times: 1
The data access service is either not running or not yet initialized. Check the event log for more information.Stack trace.....lots of XML code...
Could not connect to net.tcp://localhost:5724/DispatcherService. The connection attempt lasted for a time span of 00:00:02:0321500. TCP error code 10061: No connection could be made because the target machine actively refused it 127.0.0.1:5724
Server stack trace....
6. Same as 4
7. Same as 5 and it continues like that for 11 attemps
X. Lfx Service: Could not start Lfx sub service with all the retries
Y: OpsMgr SDK Service: The System Data Access service failed due to an unhandled exception.
The service will attempt to restart.
Microsoft.EnterpriseManagement.Common.SdkServiceNotInitializedException: The Data Access service has not yet initialized. Please try again....
Can we please run a simple test,
I just want to confirm that port 5724 and 5723 are open.
Can you please run a simple telnet command to test this.
Well no, 5723 doesnt work on my production server either though. On the test server the firewall is turned off for all networks (same as production server), but just in case I created and outbound and inbound rule allow everything from and too everything, makes no difference.
I am going on 1 weeks leave next week but I am thinking when I can find the time, I might just start from scratch with a different approach.
Thanks for your help, but I think theres something fundamentally wrong with my test setup.
So I did have another crack at it with a DC built especially for the task as above and this time using Hyper-V guests which was a lot smoother than VirtualBox for these purposes. As mentioned before my SQL DBs are located on a dedicated server in the production environment and I couldn't use Disk2VHD on that because of the EFI System partition on it.
But following the outlined steps in the blog, I only needed to do one additional step on my test SQL server, enable CLR as per this:
So now its time for 2012 RC! :)