<div>
Look at the 2019 essential as the platform to retain access to Exchange and 10-25 users without the added costs if you were.<br />
<br />
You would run adprep in order to add the windows server 2019 schema <br />
<br />
<a href="https://social.technet.microsoft.com/Forums/windows/en-US/30152f71-21e4-41a5-a99b-27e3c1395415/upgrade-sbs-2011-to-windows-server-essentials-2019#:~:text=Yes%2C%20you%20can%20join%20the%202019%20Essentials%20to,applied%20to%20both%20SBS%202011%20and%20WSE%202019" rel="ugc nofollow">https://social.technet.microsoft.com/Forums/windows/en-US/30152f71-21e4-41a5-a99b-27e3c1395415/upgrade-sbs-2011-to-windows-server-essentials-2019#:~:text=Yes%2C%20you%20can%20join%20the%202019%20Essentials%20to,applied%20to%20both%20SBS%202011%20and%20WSE%202019</a>.<br />
<br />
Double check how your sysvol is setup.<br />
NTFRS or DFS-R<br />
<a href="https://docs.microsoft.com/en-us/windows-server/storage/dfs-replication/migrate-sysvol-to-dfsr" rel="ugc">https://docs.microsoft.com/en-us/windows-server/storage/dfs-replication/migrate-sysvol-to-dfsr</a><br />
do this first.<br />
<br />
Are you virtualizing? One windwos 2019 Standard server with one VM windows Essential<br />
<br />
IT gets complicated since the person waited this long. <br />
The 2016 is a fairly straight forward and many MS docs have step by step.<br />
<br />
Are you going for the subscription model?<br />
<br />
Best to talk an MS reseller describe the setup.<br />
Purchasing A volume License would grant you access to a VM running essential.<br />
<a href="https://www.microsoft.com/en-us/windows-server/pricing" rel="ugc">https://www.microsoft.com/en-us/windows-server/pricing</a><br />
<br />
This may help i.e. setup hyper-v with 2019, load 2016 VMs migrate the SBS2011 to the 2016 and then go from 2016 to 2019 with new VMs for the transition..
</div>


<div>
Not sure if the client's insisting on anything (other than NOT wanting cloud based Exchange), but in my opinion, as the IT person, YOU (as the IT person) should be recommending, explaining, and implementing the technology.<br><br>First, why aren't you virtualizing? &nbsp;Virtualization is NOT new technology. &nbsp;It's been a main stream part of Windows for WELL OVER a decade (Hyper-V) and very common process even before that with VMWare. &nbsp;There are MANY reasons you want to virtualize and FEW reasons you shouldn't (If any; you should not be asking why should I, you should be asking why shouldn't I?)<br><br>Please see my article:<br><a href="https://www.experts-exchange.com/articles/27799/Virtual-or-Physical.html" rel="ugc">https://www.experts-exchange.com/articles/27799/Virtual-or-Physical.html</a><br><br>So, assuming you virtualize, I would recommend building a new domain so you can get rid of the .local domain name (and legacy SBS policies and registry settings) and setup a new domain name based on the client's public domain - <a rel="ugc nofollow" target="_blank">ad.clientpublicname.com</a>&nbsp; <br><br>Then I would setup Hyper-V on a new server, install a VM for the DC/File Server and a VM for the Exchange Server.<br>Setup the servers, then repurpose the old server as a Hyper-V replica server, replicating the two main VMs to the old server. &nbsp;In the event of a failure of the main server, you can restore services to within minutes of the failure in a very short time, minimizing downtime. &nbsp;As opposed to two physical servers where if one goes down, you're scrambling to get that working and the client is unable to work for hours or possibly even days!
</div>


arnold

<div>
<blockquote><ul><li>After joining the 1st 2019 Server to the SBS2011 domain, it will inherit the Exchange 2010 schema that exists in the AD.&nbsp;</li></ul></blockquote><br>When you promote the server as a domain controller, yes it will replicate AD and DNS zones to that server.<br><br><blockquote>Will this introduce issues to the new Exchange Server?</blockquote><br>yes...it won't work<br><br>SBS 2011 runs Exchange 2010 which can't co-exist with Exchange 2019<br>you need to either install Exchange 2016 first, cleanly remove SBS then go to 2019 or build a new domain - which would require exporting all mailboxes to pst files then importing once the new domain (server essentials) and exchange environment is running<br>all systems would need to be removed from the old domain and added to the new one. &nbsp;might not be too bad since there are only 10 users<br><br>or move to microsoft 365...probably cheaper in the long run and less to manage for only 10 users<br><br><blockquote>The catch - the existing SBS2011 server is being repurposed as the 2nd Server 2019 server running Exchange 2019.</blockquote><br>what kind of hardware is it? &nbsp;system requirements for exchange 2019 are much higher than SBS from a decade ago and i'm doubting it will be sufficient
</div>


<div>
Anrold, Lee and Seth,<br><br>How about you re-read the question and provide answers that reflect those asked. &nbsp;It saves you guys wasting time typing irelevant information and wasting my time.&nbsp; Thanks
</div>


<div>
I feel you are fundamentally wrong in your approach. &nbsp;I'm trying to help you and your client have the best experience possible and offer you a solution that you may not have considered before that offers a more resilient configuration that implements modern best practices (sans reasons NOT to use them). I thought I was clear on that. &nbsp;<br><br>In particular, one of your points was:<blockquote><ul><li>I have always favoured a new domain to get rid of corruptions, legacy AD content added by past applications (especially sites that dont have UPS's to protect the server aganst sudden loss of power resulting in Ad corruption). &nbsp;Is my bias to this wrong?</li></ul></blockquote>To that end, I provided an answer:<blockquote>I would recommend building a new domain so you can get rid of the .local domain name (and legacy SBS policies and registry settings) and setup a new domain name based on the client's public domain - <a target="_blank" rel="ugc nofollow">ad.clientpublicname.com</a></blockquote>Good luck<br><br>Edit: Additionally, you posted in a forum that is readable by others. &nbsp;Sometimes people search for answers and while our recommendations may not be exactly what you're looking for, as a discussion, others may find them useful.
</div>


<div>
The client has already puirchased the HW.<br>They do not want the added cost of virutalization (licensing, purhase of a server with sufficient grunt, ongoing support load)<br>My bigger sites are virtualised on VMWare and use SANs where appropriate, in this case they are a small business and have every right to nominate what they want done and the cost they wish to incurr.<br>There are several KB articles covering the removal of SBS material but I havent located one covering the Exchange 2010 Schema.<br><br>What do you feel is fundamentally wrong?<br><br>
</div>


<div>
You can end up with the setup they want while simplifying the transition.<br />
Are you intending to setup a new domain?<br />
Presumably, you would need to check whether the current exchange setup includes auto-archiving to account for a coplete data export.<br />
<br />
Then deal with shared folders, mailboxes, distribution lists.<br />
<br />
If memory serves, those can be scripted....
</div>


<div>
<blockquote>How about you re-read the question and provide answers that reflect those asked.</blockquote><br>I did. &nbsp;You said you will introduce the 2019 server to SBS which means you are upgrading your domain and migrating Exchange. &nbsp;I said it won't work because the 2 versions can't co-exist. &nbsp;You also didn't answer the question about the SBS hardware which is likely insufficient for a 2019 Exchange server.<br><br><blockquote>It saves you guys wasting time typing irelevant information and wasting my time.</blockquote><br>Not irrelevant at all. &nbsp;Arnold brought up some good technical details to consider and Lee provided practical feedback around virtualization which is a more modern approach. &nbsp;No need to respond that way if the organization is so hard-pressed to go in a different direction. &nbsp;If you stated in the beginning folks weren't interested in virtualizing and wanted to stay with a bare-metal migration, you would have got a different response. &nbsp;You came here for expert advice and you got it. &nbsp;We provided answers based on what limited details you gave.
</div>


<div>
Hi Seth,<br><br>I didnt include the age of the old server becasue it wasn't relevant to MY Q, nor Virtualisation, the biggest issue is:<blockquote><em>After joining the 1st 2019 Server to the SBS2011 domain, it will inherit the Exchange 2010 schema that exists in the AD. &nbsp;Will this introduce issues to the new Exchange Server?&nbsp;</em></blockquote>if the question is broken down:<blockquote>the existing SBS2011 server is being repurposed as the 2nd Server 2019 server running Exchange 2019</blockquote><div><em>The two will only co-exist when the new server is introduced to the OLD domain to receive the AD DB, once the 2019 ADC &nbsp;is in place the SBS server will be wiped and rebuilt with server 2019 to host exchange 2019.</em></div><br><strong>I concede that perhaps I should have added "how sucessful are the assorted methods of removing the old schema from the upgraded AD DB?" &nbsp;</strong>I recall at one of MSFT's Exchange days at their offices here that a comment was made that some config items for exchange weren't stored in the Exchange part of the schema in AD, and were being written to other sections of the AD for some reason, but couldnt recall the specifics, nor if it was still relevant. &nbsp;I didnt know that if I delete the old Exchange Schema from AD and missed the the others, if that was a recipe for problems now or later<br><br>I apologise to all for this aspect. &nbsp;I am not so sure I am wrong in not seeing value with the other reponses.<br><br>Sometimes I suspect responders are too quick to respond in the name of keeping their "stats" high. &nbsp;I'd prefer they read the Q, digest the information provided and respond accordingly.<br><br>Anyhow, I am building a new domain. &nbsp;The old server is not powefull enough as a VM Host, but will be fine for a 10 user domain. &nbsp;Thanks to everyone for their input.
</div>


<div>
You clearly have the skills and knowledge. <br />
Small Businesses are especially averse to change as at times the more complicated it sounds, they interpret it in a higher cost to them.<br />
With that said, they commonly stay with what they know.<br />
<br />
If you take the time to point out the options and potentially the cost savings <br />
DO they have a backup setup?<br />
<br />
Everyone relies on what they know. You are on the ground so you can and seemingly have determined that the purchased hardware does not lend itself to a virtualization environment. What is missing? What would be required to meet spec?<br />
<br />
Small business people, if better options are made available will see opportunities all around on things they had in mind but thought to be too expensive to implement.<br />
<br />
Did the cost of software in the intended implementation been determined?<br />
<br />
potentially, virtualization with additional RAM as I suspect this is what might be needed, could save a significant amount since it might be possible to get a windows server 2019, and run a VM with Windows server 2019 essentials which entitles the firm to use up to 25 users and 50 devices without any additional cost of CALS.<br />
<br />
Much depends on what the business does, you can introduce them to document management, sharepoint internally or given the O365 online is seemingly out, though what comes with that is access to the newest office suite as long as they maintain the subscription.<br />
<br />
I get your dilemma, would stirring them in one way reduce their need of my services? <br />
You could be the catalyst for their growth and expansion!
</div>


<div>
HI Arnold.<em><br></em><br>You get it. I put all the options on the table months ago. &nbsp;It's their right to choose what fits their budget, their style of use, and the things such as the software they use to manage the practice, and its now up to me to deliver on that. &nbsp;I always tell clients - lets find a soution that fits you - not what fits MSFT's profit margin :)<br><br>The SMB space is way different from my days in the enterprise at CSC etc or as the IS manager for an org where I choose the outcomes. &nbsp;My big name competitors make that mistake often and is a large part of why my business is closed to new clients<br><br>They saw no value in things like M365, everything goes into the practice management solution (PMS), these are people who have empty inboxes/sent items because of their judicious use of their PMS. &nbsp;They've spent big on comms - 5 internet providers in 4 years trying to get better connection to the world and decided the risk is too big for them. &nbsp;It's the way they like it.<br><br>While not pertinent to the question, their SW vendor does not support virtualisation of their platform,or Office &nbsp;- I can disagree until I turn all shades of blue in the face arguing it with the Vendor, but they set the rules and my client wants to use their product. &nbsp;(heck I am surprised the vendor runs on 64 bit OS - its MAC ported to MSFT). &nbsp;Some would say - tell em to change - I could but at the risk at looking as big a fool as those who suggest it.<br><br>With regards to backup setup - no. Its been something that haunts me, but while I recommend it strongly most of my clients have declined. &nbsp;The one time a client had a buidling burn to the ground I still had them back on air in a portable office block the next day. &nbsp;That was the last server/platform fail any clients has had.<br><br>Dilema - none, all clients get what is called The Dossier and<em>&nbsp;</em>its 1st paragrahs states<em>:<br><br></em><blockquote><div><em>".....this document records all details that are needed to set up your environment from scratch... &nbsp;It also allows the client to chose another provider with minimal cost and incovenience... in the event you feel 'insert my company name' is no longer suited to your needs</em>".&nbsp;</div></blockquote><br>It has everything they need to walk to a competitor any time they like, no contracts, no obligations to use me. &nbsp;It helps when I discharge a client that I think is too big a risk or not a good fit for me, I help them find a suitable competitor and move on. &nbsp;In 12 yrs I've had two clients depart - competing real estate agents who found out I looked after them both, hated each other with a passion, and both dropped me like a hot potato :)<br><br>Anyhow I've spent too much time on this already, the new domain was built and the old server went live on their new environment from last night. &nbsp;I called them this morning and was asked "did you forget our project last night?" Not one iota of recgnition of the work done ln the last 24 hrs - love it<br><br><br><br><br><br>
</div>


Owner

mbkitmgr

<div>
<div class="content wysiwyg-content fr-view">
I have a client who has stood their ground with SBS 2011 until now and needs to be migrated from 1 single server running SBS2011 to two server 2019 servers, one running Exchange. &nbsp;There are only 10 users<br><br>The catch - the existing SBS2011 server is being repurposed as the 2nd Server 2019 server running Exchange 2019.<br><br>I am considering two methods<ol><li>Build the 1st 2019 server and join to the SBS domain to receive the AD, export the mailboxes from the existing 2010 Exchange, wipe the SBS server and install server 2019 + exchange 2019, import emails....</li><li>Build a new domain altogether on the new server, export the mailboxes from the existing 2010 Exchange, wipe the SBS server and install server 2019 + exchange 2019, import emails....</li></ol><br>My questions:<ul><li>has anyone planned and executed either of these migration scenarios and can provide some tips?</li><li>After joining the 1st 2019 Server to the SBS2011 domain, it will inherit the Exchange 2010 schema that exists in the AD. &nbsp;Will this introduce issues to the new Exchange Server?</li><li>I have always favoured a new domain to get rid of corruptions, legacy AD content added by past applications (especially sites that dont have UPS's to protect the server aganst sudden loss of power resulting in Ad corruption). &nbsp;Is my bias to this wrong?</li><li>Do you have good case that would sway me to one method?</li></ul>
</div>
</div>



I have a client who has stood their ground with SBS 2011 until now and needs to be migrated from 1 single server running SBS2011 to two server 2019 servers, one running Exchange.  There are only 10 users
The catch - the existing SBS2011 server is being repurposed as the 2nd Server 2019 server running Exchange 2019.
I am considering two methods
Build the 1st 2019 server and join to the SBS domain to receive the AD, export the mailboxes from the existing 2010 Exchange, wipe the SBS server and install server 2019 + exchange 2019, import emails....
Build a new domain altogether on the new server, export the mailboxes from the existing 2010 Exchange, wipe the SBS server and install server 2019 + exchange 2019, import emails....
My questions:
has anyone planned and executed either of these migration scenarios and can provide some tips?
After joining the 1st 2019 Server to the SBS2011 domain, it will inherit the Exchange 2010 schema that exists in the AD.  Will this introduce issues to the new Exchange Server?
I have always favoured a new domain to get rid of corruptions, legacy AD content added by past applications (especially sites that dont have UPS's to protect the server aganst sudden loss of power resulting in Ad corruption).  Is my bias to this wrong?
Do you have good case that would sway me to one method?

Migration from sole SBS2011 server to Server 2019 + Exchange

Exchange is the server side of a collaborative application product that is part of the Microsoft Server infrastructure. Exchange's major features include email, calendaring, contacts and tasks, support for mobile and web-based access to information, and support for data storage.

Exchange

Windows Server 2019

Small Business Server (SBS) is a line of server operating systems targeted at small businesses by bundling the operating system with a number of other Microsoft products that would normally need to be purchased or licensed separately. The most notable inclusions are Exchange, SQL Server, SharePoint and ISA/TMG (Microsoft's firewall and proxy server).

Active Directory (AD) is a Microsoft brand for identity-related capabilities. In the on-premises world, Windows Server AD provides a set of identity capabilities and services, and is hugely popular (88% of Fortune 1000 and 95% of enterprises use AD). This topic includes all things Active Directory including DNS, Group Policy, DFS, troubleshooting, ADFS, and all other topics under the Microsoft AD and identity umbrella.