The web of trust being broken doesn't by itself mean the security of SSL is useless, just a bit less trustworthy. Self signed SSL certs are every bit as strong as a certified one at the same level of course just not verified who the end point is.

Something I haven't seen mentioned here, When you join another DC to your SBS Domain, you have either 15 or 25 days (I just can't remember now) to turn off the old SBS server or it will start turning itself off - FYI.

You have to set the permission. They don't magically appear. I don't mean to sound curt, I want to make sure we're on the same page. You'll have to set the permissions manually on the sharepoint itself (like your did years ago on the old server) and when using Robocopy supply the correct arguments so that file level permissions are kept during the file copy (I hope you have full access - If you don't I'm not sure how to get around that).

The awesome power of the moon!

@IRJ said:

@Dashrender said:

O'Rielly's is currently selling all of their MS Press books for 60% off - full non DRM ebooks. I picked up Excel and Outlook 2013.

Its alot easier to get an end user to participate in online training vs reading a book, though.

You're absolutely correct - but if this is for someone who's reading these forums.. there's a good chance they'd be at least willing to flip through a book, even if they don't read it cover to cover.

@garak0410 said:

I am moving the files AFTER I promote the new one and demote the other one, correct? Or in between the promotion and demotion? (and yes, plan on keeping them on the root of D)

Actually you could move the files anytime after you join the new server to the old Domain. Once that is done, the new server will understand the security principals of the domain and you'd be covered. Now, that being said, I would wait until after you promote the new server to an AD DS server, but you don't have to.

O'Rielly's is currently selling all of their MS Press books for 60% off - full non DRM ebooks. I picked up Excel and Outlook 2013.

@garak0410 said:

• If I migrate, the domain remains the same, correct?

Yes

• If I move the file server to a separate VM, as long as my domain name doesn't change, I should be good, right? That is, permissions to the file server should be OK?

How would you move the file server without moving files? The only thing that makes a file server a file server is the files it serves. The permissions are what you set them to be. Using Robocopy will help in keeping them the same as they were in the old file server. (FYI - MS changed the default permissions on folders I think in Windows 2008 Server - I'd setup the root folder to be the same as the root folder on your old SBS server before you use Robocopy just to make sure don't run into more problems.

Looks like a good start. As Scott mentioned, some of the things in that list are out of order - but looks good.

Now you need to add on all of the other migration things. Email, AV, DBs, Printers, Files, etc.

@Bill-Kindle said:

@Dashrender Dayumn. Thats some deep discount on the ebook versions too! Just need to get 70-411, and 412 exam refs and maybe a couple more pocket refs........does someone smell something burning ?

agreed, Windows 2012 (R2) have changed thing a lot - I know I'm missing out on all the latest and greatest things I should be doing - time to learn and at a great price.

@DenisKelley said:

@Dashrender said:

WOW! now this is pretty cool. Appasure (at leave version 4) would somehow confirm it's backed up image was good - but I don't recall hearing it was anything like this.

Sorry, can't believe I'm geeking out over a backup product. LOL

eh.. it's technology, today it's backup products, tomorrow it's the new swatch.

@scottalanmiller said:

As for share names, you can fix that by abstracting in DNS. For example, if the old server (sbs2003srv) has a DNS CNAME of fileguy then people would access \fileguy\public\dilbertcomics\

When migrating to a new file server, you would need to do nothing but copy the data and repoint the CNAME.

This assumes you're able to shut the old server off as soon as you've moved the data.
I suppose another option going forward would be to create a generic cname pointing to the current location of the data, then in the future you can change it to point to the new new server, but why? DFS I'm sure for something (that I don't currently know, other than you can introduce replication) is a better solution.

@DenisKelley said:

It's also a great way to test. I use it when I want to play with new things without breaking my production boxes.

Do I assume correctly that you're running Veeam as a guest on a VM host? How much resources do you dedicate to the Veeam instance?

WOW! now this is pretty cool. Appasure (at leave version 4) would somehow confirm it's backed up image was good - but I don't recall hearing it was anything like this.

@garak0410 said:

So, if I migrate, my domain name stays the same, correct? Just the server name will change, correct?

Correct. Just the server name changes. But this can and does effect a lot.

For example your file shares. Today they are probably something like \sbsserver\share and after you move to 2012R2 they will change to \2012r2server\share. This means that you have to update all of the connection points that are pointing to the old files shares (normally done through a logon script).

To save yourself this hassle in the future, you can setup DFS now this will change your connection points a little, to something like \domain.name\share\folder The good thing is that in the future when you have to this again, you won't have to change the logon scripts because the \domain.name portion never changes, and you can do all of the changes behind the scenes.

Also don't forget about things like your AV console. If the clients connect to a specifically named server you'll need to change them to point to the new one.

@DenisKelley said:

Oh, and if you are using Veeam Essentials Enterprise (needed for GRT of application items), you also get one of my favorite features. That feature is their isolated lab. One of the things as admins we need to know is whether or not our backups are good. Well, Veeam gives you an awesome way to do that. For each backup I have, after completion, Veeam launches that backup as a full restore in that isolated lab to make sure it boots, can be logged in, can talk to AD, and for special stuff like SQL, Exchange, and SharePoint, will run application specific scripts to test the backup.

Wow.. that sounds pretty cool - but if you're not running AD on the Exchange server, does it also spin up an AD in the lab setting for the SQL and Exchange boxes to talk to?

Are you migrating from and SBS system to a Windows Server 2012 R2? There are migration paths for this that don't require making new domains. This keeps you from having to recreate all of the users, move the computers to a new domain, fix profile problems from logging onto a new domain, etc, etc, etc.

If you are moving from a Windows Server 2003, 2003 R2, 2008, 2008 R2 or 2012 domain (NON SBS) then life is relatively simple.

@garak0410 said:

OK...so when I Robocopy them over, it doesn't matter if domain has changed or if I now have a new file server, as long as it is on the new domain, the permissions (based upon groups and users) should carry over, correct? Again, sorry for my ignorance. I will look at DFS if I have time.

Sorry I didn't realize you were changing domains (why are you doing that?). You'll lose all of the SID associations when you change domains so your permissions won't flow if you are changing domains.

Those look familiar, we rolled out about 10 last year too. and now i'm about to roll out the new 800 G1s

File permissions have nothing to do with the server they are on, and more to do with the files themselves. Now that being said - the folders that files are in typically push their permissions down to the files.

When you copy your files from the old server to the new one - use something like Robocopy and use the commands that keep the file permissions the same on the copied files.

Also - now is a great time to look at setting up DFS instead of old school UNC shares. This will make life easier for you in 4-7 years when you have to migrate again.