Thanks everyone for the information! Mark Kent Manager, Client Systems Engineering Technology Support Services Resources for Information, Technology and Education (RITE) http://rite.buffalostate.edu<http://rite.buffalostate.edu/>
From: [email protected] [mailto:[email protected]] On Behalf Of Jason Sandys Sent: Friday, October 7, 2016 11:00 AM To: [email protected] Subject: RE: [mssms] RE: Question on migration Yes, although restoring to a newer version of SQL is supposed to work as well – can’t say I’ve tried that though. Also, the server name has to be the same (just stop the services – ConfigMgr and SQL – and rename the old server) and the drive layout on the new server should be the same (I think it’s supported to change that now but I wouldn’t open that box). J From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Mawdsley R. Sent: Friday, October 7, 2016 9:14 AM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] RE: Question on migration Ok that’s interesting. To confirm then, I would need to build the new infrastructure on Server 2012/2016 machines, install SQL as the same version it currently is, restore the site, then in-place upgrade of SQL? Rich From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Jason Sandys Sent: 07 October 2016 14:17 To: [email protected]<mailto:[email protected]> Subject: Re: [mssms] RE: Question on migration Generally, yes. It’s faster and easier and you have an easy fallback method as well. Also, you get to test your DR procedures (which I’m sure you’ve tested many time before ☺). J From: <[email protected]<mailto:[email protected]>> on behalf of "Mawdsley R." <[email protected]<mailto:[email protected]>> Reply-To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Friday, October 7, 2016 at 3:44 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: RE: [mssms] RE: Question on migration Because that’s how it was configured when I got here! ☺ So you would recommend I setup the new infrastructure and then restore to it, instead of a migration then? Rich From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Jason Sandys Sent: 06 October 2016 13:54 To: [email protected]<mailto:[email protected]> Subject: Re: [mssms] RE: Question on migration Those would be separate operations just like they are today; neither overly difficult either. Why would you separate your SQL Server though? That’s a [very] bad idea in general: https://stevethompsonmvp.wordpress.com/2014/12/20/why-you-should-not-use-remote-sql-server-with-configmgr-2012/ J From: <[email protected]<mailto:[email protected]>> on behalf of "Mawdsley R." <[email protected]<mailto:[email protected]>> Reply-To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Thursday, October 6, 2016 at 5:18 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: [mssms] RE: Question on migration How does backup and restore hold up if you’re wanting a different configuration of Site Servers? For instance, we currently have SQL and WSUS both on separate boxes from the Primary.. when we move to Server 2012/2016 by year end, we want to have these locally on the Primary Server instead. How would it hold up in this scenario? Rich From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Jason Sandys Sent: 05 October 2016 21:41 To: [email protected]<mailto:[email protected]> Subject: [mssms] RE: Question on migration Not true, it’s totally supported. You can always do housekeeping. Why migrate anything at all though is the point? J From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Marcum, John Sent: Wednesday, October 5, 2016 2:40 PM To: '[email protected]' <[email protected]<mailto:[email protected]>> Subject: [mssms] RE: Question on migration Because backup and restore to a new OS is unsupported. I’ve done a couple of them this way and it’s really easy. Also presents an opportunity to do some housekeeping. There’s only a very small list of things that can’t be migrated. Some need to be done outside of the little wizard but almost everything can be done. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Jason Sandys Sent: Wednesday, October 5, 2016 2:02 PM To: [email protected]<mailto:[email protected]> Subject: [mssms] RE: Question on migration [External Email] Too much work. Why would you stand up a whole new site, migrate nearly everything – not everything can actually be migrated – redeploy all of the clients, redeploy content or fight with shared DPs, etc., etc. A backup and restore can be done easily within a day, tests your DR procedures in the process, and doesn’t require you to reconfigure anything. J From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Spengler, Jeff Sent: Wednesday, October 5, 2016 1:18 PM To: '[email protected]' <[email protected]<mailto:[email protected]>> Subject: [mssms] RE: Question on migration Just curious..why never recommend a migration? From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Jason Sandys Sent: Wednesday, October 05, 2016 11:46 AM To: [email protected]<mailto:[email protected]> Subject: [EXTERNAL] [mssms] RE: Question on migration First a quick note, if you’re on Server 2012, then you don’t have WSUS 3. I would never recommend a migration unless you have some external constraint. Upgrading SQL in-place is almost trivial and works quite well. Upgrading ConfigMgr in-place works well as well. If you want to build new, site backup and restore to the new server is the best path and involves the least disruption. You can perform all of your in-place upgrades on the existing server and then backup and restore to the new server with like version of everything installed but no remnants of anything old. J From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Kent, Mark Sent: Wednesday, October 5, 2016 11:45 AM To: '[email protected]' <[email protected]<mailto:[email protected]>> Subject: [mssms] Question on migration We are currently on SCCM 2012 R2 SP1. It runs on a Server 2012 (nonR2) server with SQL 2012 on box. We also run WSUS 3 and MDT (latest) on the same box. We also have three Server 2012 R2 servers running DP’s (including PXE) and MP’s. We need to make the move to SCCM CB, for obvious reasons, and I’m wondering what the consensus would be on a migration strategy. Do we attempt to update the server to R2, and then update SCCM, and the various pieces (SQL, MDT, etc.) after that. Or is it advisable to build a new 2012 R2 server (2016?) and try and migrate over to it? I’m looking to minimize downtime (who doesn’t). I’m a little concerned about running numerous upgrades, sometimes it’s like rolling dice, but if that’s the best route I’ll do that. I’d love to build new if possible, I just don’t know how complex that would make the migration and if that would take longer. I should mentioned our Db had some minor corruption a few times, requiring repair with data loss. From what we gathered, it was due to the fact we were gathering too much process data which was filling up the Db quite a bit. Once we removed the amount of info that was being gathered from processes, the Db size went down and the corruption ended. Just looking for some pointers from anyone who has done this already, thanks! Mark Kent Manager, Client Systems Engineering Technology Support Services Resources for Information, Technology and Education (RITE) http://rite.buffalostate.edu<http://rite.buffalostate.edu/> --------------------------------------------------------------------- [aho Power Legal Disclaimer] This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. --------------------------------------------------------------------- ________________________________ 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.
