That sounds great.... I assume you just built up a new parallel environment? Any good way to get the configs from prod over to dev to 'seed' it so to speak or am I pretty much stuck with building a dev from scratch (if I choose to connect to production network).
Thanks for taking the time to answer ... I really need to come up with something as the solutions people are asking for really need testing before sticking in the prod environment. From: [email protected] [mailto:[email protected]] On Behalf Of Presley, Dow Sent: Thursday, August 1, 2013 9:03 AM To: [email protected] Subject: RE: [servman] SCSM Upgrade in Lab then Move to PRD We have a DEV instance connected to our production network, which I use heavily since we do all of our development and testing in that instance. It is configured very similar to production and has the SCCM connector and other such connectors running just the same a production. However, to prevent confusion that would be caused by notifications being sent from this instance during testing I do not use the Exchange Connector to connect to Exchange. Instead I use a tool called 'SMTP4Dev' and I connect the Exchange Connector to that. Any e-mails that would be sent can be seen in this tool and I can verify my notifications without the chance of sending out e-mails that would confuse my users. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Robertson, Casey Sent: Thursday, August 01, 2013 10:19 AM To: [email protected]<mailto:[email protected]> Subject: RE: [servman] SCSM Upgrade in Lab then Move to PRD Appreciate the feedback and steps below. I keep going back and forth because there would be advantages to running something on our production network in 'test' mode (so that we could interact with Exchange or other services) but also the inherent risk with this. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Presley, Dow Sent: Monday, July 29, 2013 1:14 PM To: [email protected]<mailto:[email protected]> Subject: RE: [servman] SCSM Upgrade in Lab then Move to PRD Microsoft has an official method for setting up a lab environment with production data as defined at the following link: http://technet.microsoft.com/en-us/library/jj900180.aspx We did something simpler using a sandbox completely isolated from our production network: 1) We snapshotted the VMs for our management, DW, and portal servers and copied those over to the sandbox. 2) We snapshotted an AD server and copied that over as well. 3) We built a SQL Server machine in the sandbox. 4) We backed up the production database, copied it to the sandbox, and restored it on that SQL Server. This worked but Microsoft emphasized strongly that it was not supported. Of course, since we were just using it for testing that did not really matter. Unfortunately, the problem we were having in production (as described in this thread) did not occur during the testing. That eventually led us to believing that the problem might not occur if the database was not clustered. Thus we did as Brody stated and moved the database to a dedicated server, performed the upgrade, and then moved the database back to the cluster. Thanks, Dow From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Brody Kilpatrick Sent: Monday, July 29, 2013 2:33 PM To: [email protected]<mailto:[email protected]> Subject: Re: [servman] SCSM Upgrade in Lab then Move to PRD The upgrade was successful by moving the database off the cluster onto a dedicated server, performing the upgrade, and then moving it back to the cluster. On Mon, Jul 29, 2013 at 1:47 PM, Robertson, Casey <[email protected]<mailto:[email protected]>> wrote: Just curious what ever came of this... Semi-related... is there a good fool-proof procedure for creating a lab environment from you current production system? My 3 servers (management, dw management server and portal) are all VMs. SQL is remote. I'm being asked to test/try some things esp. with runbooks that I don't want to run in production. But it would be VERY nice to have it set up like my current prod environment. Thanks, Casey From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Travis Wright Sent: Wednesday, May 1, 2013 12:02 PM To: [email protected]<mailto:[email protected]> Subject: RE: [servman] SCSM Upgrade in Lab then Move to PRD I've heard that we have our best escalation engineer assigned to the case now. Let me know if you don't start getting traction in the next couple of days. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Hemsell, Todd Sent: Wednesday, May 1, 2013 12:53 PM To: [email protected]<mailto:[email protected]> Subject: RE: [servman] SCSM Upgrade in Lab then Move to PRD case has been open for months now. We already have demos scheduled with ServiceNOW :-( They are going to drop the entire system center suite pretty soon. ________________________________ From: [email protected]<mailto:[email protected]> [[email protected]<mailto:[email protected]>] On Behalf Of Marcum, John [[email protected]<mailto:[email protected]>] Sent: Tuesday, April 30, 2013 6:56 PM To: [email protected]<mailto:[email protected]> Subject: RE: [servman] SCSM Upgrade in Lab then Move to PRD I'm not a SM guy but I'd be very surprised if that's even close to being supported. Will it work? Maybe so but MS only supports tested scenarios and I doubt they tested that. Why not just call MS And make them fix the issue in the PRD upgrade? From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Brody Kilpatrick Sent: Tuesday, April 30, 2013 10:02 AM To: [email protected]<mailto:[email protected]> Subject: Re: [servman] SCSM Upgrade in Lab then Move to PRD During the upgrade, it fails while making a modification to a stored procedure. A SQL trace shows the stored procedure running, but the stored procedure times out. From my understanding, in that particular stored procedure inside the upgrade, there is a hard time out. In terms of SQL Server configuration query and timeout connections are all set to unlimited. It consistently fails on the same procedure each time, and always with a time out error as shown in the trace. On Tue, Apr 30, 2013 at 9:52 AM, Travis Wright <[email protected]<mailto:[email protected]>> wrote: What is the issue that is happening with upgrade? Why would snapshotting it to test and back help solve that problem? From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Brody Kilpatrick Sent: Tuesday, April 30, 2013 7:24 AM To: [email protected]<mailto:[email protected]> Subject: [servman] SCSM Upgrade in Lab then Move to PRD I have a client that has a production SCSM 2012 installation. We are having trouble upgrading to SP1 in production, and have very limited windows/chances to upgrade. I want to throw the below question out to see if Microsoft will support this approach to the upgrade. I believe it is our only option. Otherwise, the client is looking to remove SCSM from their environment and replace it with another solution. Wi Will Microsoft Support the following upgrade method: a. Take a snapshot of the SCSM Production Environment b. Enter the Environment into a LAB c. Upgrade SCSM to SP1 and the latest CU d. Verify the Upgrade is successful e. Migrate the Lab installation into Production via Snapshot and Database Restore -- Thank you, Brody Kilpatrick -- Thank you, Brody Kilpatrick ________________________________ Confidentiality Notice: This e-mail is from a law firm and may be protected by the attorney-client or work product privileges. If you have received this message in error, please notify the sender by replying to this e-mail and then delete it from your computer. ________________________________ Confidentiality Notice: This e-mail is from a law firm and may be protected by the attorney-client or work product privileges. If you have received this message in error, please notify the sender by replying to this e-mail and then delete it from your computer. -- Thank you, Brody Kilpatrick
