TR Forums

So I have an interesting (for some) project. I've been brought on as sole IT guy at a fairly small (~25 seat) local business. I've inherited a lot of existing, preconfigured infrastructure.

In particular, we have this poor little SBS 2011 machine. It's got fairly good hardware, 8GB of ram, and it's doing NOTHING, yet it's somehow always maxed out. It's pegged for CPU, RAM, and I/O, pretty much 24/7. The biggest offender may be this backup script that's running. It's having problems, running poorly, and generally being troublesome.

That said, Exchange. We don't use it, never have, and have no plans to ever run it in house.

I would never have signed off on SBS2011 over 2008 R2, given our usage. Since I'm stuck with it for the time being, anyone had any experience slimming the install down any? Everything I read says to touch nothing, it's all hyper-integrated. That said, I looked over the list of things that would or might break, decided to gamble, and manually shut down Exchange. Only a few of the things listed actually broke, and we don't use any of those or their dependencies, so all good. The box got back about 800MB of RAM and a small amount of CPU and I/O time. Any other ideas, or should I just get it swapped out for a 2008 R2 install ASAP?

In my experience, SBS systems are really just a domain controller with Exchange built in. That was really the appeal to it, as it was quite a bit less expensive than a Server 2008 R2 and Exchange license. Since you've disabled the Exchange component with little issues, what are the other roles the server is actually preforming for the organization?
- Is it hosting user accounts for authentication?
- Is it setup as a file server in any way?
- Are other services such as IIS, DNS or DHCP active on it?
You mentioned the backup script was having problems, and I admit that I usually avoid the SBS backup client at all costs.

But with all that said, what exactly do you intend to gain from moving the OS to Server 2008 R2 seeing as SBS 2011 itself is based on Server 2008 R2.
Appart from the fact it will no longer be SBS, of course.

<PUI> Well, mostly I just want it not to be such a drunken hog. Thing has 8GB of ram and a halfway decent i5-alike Xeon in it, it's only doing AD and some file serving. The file serving is fast enough, apparently the "consultant" enabled folder redirection on it, but it was too slow (derp). Right now it's just providing public folders ( which no one uses) and some generic public file space. It does IIS/DNS/etc, but only as far as required to support AD ops and WSUS ( which is dumb for us, cause we have fast net and had no approval policies). It really irritates me because it came with Srv2008r2, which is fine, but the consultant talked them onto buying SBS. Anyways, it's slow.

Well, if you already have a Server 2008 R2 license for the box, then I would definately agree that rebuilding it would be the best plan. That way you can get the junk services all out of the way, like the redirection and public folders. A rebuild shouldn't take very long at all for an organization that size.
I'm sure there are others out in TR land who can offer more specific advice.

Yeah, that's probably the best way to go. I'll probably recruit a machine from home, put on 2008R2, promote that to PDC, migrate the stuff I want to keep across, reformat/reinstall/rebuild the current machine to 2008r2, then promote that back up to PDC. That's going to take more time than I have for a while, but thanks for confirming my theory.

<PDC>

I'd agree. There's a place for SBS, but if you're not using all the stuff it comes with (particularly Exchange), it's just going to require a ton of resources for no gain. It seems under-powered too, the ones I've deployed have 16GB of RAM and do okay. Your system will do a lot better with 2008 R2 just doing AD and file services.

We did have a SBS 2008 where the SBS Monitoring stuff went haywire and brought the thing to its knees. Disabling it just keeps the SBS console from reporting stuff, which we didn't find necessary. Could be something for you to look at in the mean time.

Another vote for dropping SBS and install 2008 R2. I recently installed a 2008 SBS (from the previous tech) that sat in box for the better part of a year. It was just a pain and a hog to the point that I wiped the sucker clean, installed 2008 R2 on it and never looked back. If your going to be running exchange then SBS may be a solution, but you've stated they aren't. I too was wondering about slimming down SBS, but found the same thing you do, everything (and I mean EVERYTHING) is integrated in one form of fashion in SBS. You may have found a way to disable exchange manually, but the entire AD in SBS looks to Exchange (and vice versa) for information. At the very least you'd have your Application event log spammed with warnings and errors.

Oh and I sold the SBS back to the original tech who had a use for it... so if that's a possibility /shrug.

You are probably wasting more $/hour trying to retrofit SBS to work, than you would spend by just buying Server 2008 R2. This is the wrong tool for the job.

Stop wasting your time and get Server 2008 R2.

Show your purchasing mgr how you can be more productive with the time you save, and also how much better the server will perform. We have Server 2008 R2 running on P4 boxes with old IDE drives, doing basic DNS and file serving, and for the most part, they are as smooth as butter.

FYI, Exchange runs a MS SQL datastore as well as mailbox stores which will use all available RAM. What a waste if you're not using them.

DrDillyBar pointed me to this posting, thought i might be able to add to it.

I agree with the short answer, if your not going to be using Exchange SBS is a waste of resources and you should just swap to 2008 R2.
The memory usage you were describing is common and caused by the WSUS SQL DB overrunning the ram because its memory limits are set to the default SQL instance settings, this then results in paging the DB info which will bring any server to its knee's
With that said if you want to improve some of the performance options on the SBS box without doing a complete rebuild you can uninstall the following
- WSUS including all data and databases
- Sharepoint, this will require a reboot and you will need to manually delete some services and VSS reg entries
- Disable the SBS Management and SQL (SBS Monitoring) services
- in the Task Scheduler Disable the Console task under Task Scheduler Library - Microsoft - Windows - Windows Small Business Server 2011, this will kill the sbs console from loading at login
After that if you wanted to disable exchange you could without any issues but if there are no mailboxes and its not being actively used there's not really any point as it won't be doing anything anyways. The main issue is the 3-5 SQL instances installed by default that are all fighting for memory and disk I/O that brings the system to its knee's

Hope that helps.

Regards
-----------------------------------------------------------
"Come to the Dark Side, We have Cookies!"

JdL wrote:

You are probably wasting more $/hour trying to retrofit SBS to work, than you would spend by just buying Server 2008 R2. This is the wrong tool for the job.

Stop wasting your time and get Server 2008 R2.

Show your purchasing mgr how you can be more productive with the time you save, and also how much better the server will perform.

You didn't read my first post, I'm guessing? The server itself CAME with a 2008 R2 license. What I don't have right now is the time to tear it down and put plain old 2008 R2 on there. I also can't have downtime on the server ATM, since we're on AD.

Tearing SBS out and putting a plain 2008 R2 install on is very much on my to-do. I just need to make it run a little better in the meantime.

Khitman - thanks very much, and welcome to TR! I may try to salvage WSUS just to keep patch management/approval, but I think I'll be looking into adjusting the MSSQL config right away. Exchange is already down because we've never used it, and I'll be taking a look at Sharepoint very soon. Thanks for the ideas, they're pointing me in the right direction.

Honestly, with the deeply-entrenched use of Google apps I'm seeing, I can only imagine the consultant got commission on the SBS sale, hoped to convert them to a full MS stack, or just didn't know any other way. The folks at work trust/use Google even more than I do, and that scares me a little.

Is there a reason you can't just add some more RAM, since it seems that's the bottleneck? Seems like it might be a lot cheaper and faster solution, but I'm not really a server guy.

Using Google means I have no role there.
and RAM is not really a problem.

Here is a suggestion that would render you with virtually zero down time and allow you to get that box installed with 2008 r2. Ive done this with a Dell PowerEdge 840 before that was running raid 5.

Grab a copy of a Acronis backup and recover 10 or 11 (bootable) and an external drive large enough to make an image of the system. Do a complete full backup and restore that image to another computer that can act as your server for a couple of days (using the universal restore feature). Once the temporary system is in place and everything checks out, clean off your real server and slap 2008 r2 on it. Configure it and then go about migrating your AD and other settings/data.

I did this with a normal desktop out of desperation once for a dental office and they didnt even notice their server had been changed for a week when i came in to put the real one back in.

Welch wrote:

Here is a suggestion that would render you with virtually zero down time and allow you to get that box installed with 2008 r2. Ive done this with a Dell PowerEdge 840 before that was running raid 5.

Grab a copy of a Acronis backup and recover 10 or 11 (bootable) and an external drive large enough to make an image of the system. Do a complete full backup and restore that image to another computer that can act as your server for a couple of days (using the universal restore feature). Once the temporary system is in place and everything checks out, clean off your real server and slap 2008 r2 on it. Configure it and then go about migrating your AD and other settings/data.

I did this with a normal desktop out of desperation once for a dental office and they didnt even notice their server had been changed for a week when i came in to put the real one back in.

Sounds remarkably similar to what I had in mind. I'll probably do that some weekend.

DrDillyBar wrote:

Using Google means I have no role there.
and RAM is not really a problem.

Whut??

Once you've done a migration over to 2008 R2, you'll probably want to loop back and clean out a lot of the GPOs that SBS puts in place, and restructure ADUC a bit. Nothing critical, but I like to be tidy.

absurdity wrote:

Once you've done a migration over to 2008 R2, you'll probably want to loop back and clean out a lot of the GPOs that SBS puts in place, and restructure ADUC a bit. Nothing critical, but I like to be tidy.

Speaking of which, how intrenched in GPO's and other network goodies is your current server? If its nothing other than a basic AD for logon, you could always just manually rebuild the 20-25 users. Just a suggestion as I found it easier than dealing with a migration and some of the left over/changed settings.

I apologize if this is a known known, but I wanted to remind that the Active Directory Migration Tool (ADMT) is what you're after for this transition from SBS to 2008 R2.

You can find a guide from Microsoft in this link

You can find version 3.2 in this link

I have a few tiny non-public resources available for ADMT as well. Hit me up on Steam if you're interested in those.

Welch wrote:

absurdity wrote:

Once you've done a migration over to 2008 R2, you'll probably want to loop back and clean out a lot of the GPOs that SBS puts in place, and restructure ADUC a bit. Nothing critical, but I like to be tidy.

Speaking of which, how intrenched in GPO's and other network goodies is your current server? If its nothing other than a basic AD for logon, you could always just manually rebuild the 20-25 users. Just a suggestion as I found it easier than dealing with a migration and some of the left over/changed settings.

There are clever ways to do that (Import Settings). You can carry over GPO's cross domain and a wizard will guide you through UNC and SID changes for the new domain.

Yeah, I've not had a live/production Server 2008+ AD in my hands before, so I'll be fully digesting the existing situation for some time before I make any changes to AD itself. In the meantime I'm knocking as much crud off of SBS as I can. Thanks for the links, Ryu.

Couple options:

1). Fix the slowness, should be simple enough with a little troubleshooting. There isn't a reason the box should be maxed out on everything. Even if you have to buy more ram it *might* just save you the headache. I mean, if the box runs fine after finding the bottleneck... Baby. Bathwater. KHitMaN is spot on with the SQL issues.
2). Follow one of the several options for migrating/starting fresh. Just use the built in bare metal restore option in 2008 R2. It's free and it works. Oh and get ready to buy ~20 new CALs (Yay for Microsoft licensing!)

You talk about a backup script, can you elaborate on this issue?

Jason181 wrote:

DrDillyBar wrote:

Using Google means I have no role there.
and RAM is not really a problem.

Whut??

which part?

Forge wrote:

reformat/reinstall/rebuild

Download the Proper Service Packs first.

Edit: If building a new domain, make it 2008 unless you have critical 2003's present.
/Domain Controlers.

Convert wrote:

You talk about a backup script, can you elaborate on this issue?

Oh, I really wish I could. There's an existing setup that I have to decode and understand so that I can troubleshoot. It may, in fact, be most of the issue. Now that I have Exchange out of the way, the backup mess is my next to-do. Currently there's some custom mess in there, I only got general info on it. Apparently it backs up the SBS to an external hard disk, and deltas were mentioned, so it may be incremental. There's also some black box magic going on which uses the backup to make a VM, I'm told, and the backup and/or VM is being periodically uploaded to offsite storage.

We just finished a big project this week, changed colos for the production servers, so I'm hoping I'll have more time to dig into the SBS issues.

Forge wrote:

There's also some black box magic going on which uses the backup to make a VM, I'm told, and the backup and/or VM is being periodically uploaded to offsite storage.

The builtin Windows Server Backup feature stores a bare-metal backup as a vhd. If it is doing that I can't see any reason why there needs to be any kind of custom script. If you want to upload the bat/vbs/ps1 file that is doing the actual work for the script it should be pretty easy to figure out what is going on.

I also ran into a problem like this with a client and it turned out to be the logon script and how it was sharing printers that was crippling the server. Are there any other custom scripts running on the system?

Forge wrote:

There's also some black box magic going on

tell your boss. have him click the button to break it.
Test what happens.

just a thought

LaChupacabra wrote:

Forge wrote:

There's also some black box magic going on which uses the backup to make a VM, I'm told, and the backup and/or VM is being periodically uploaded to offsite storage.

The builtin Windows Server Backup feature stores a bare-metal backup as a vhd. If it is doing that I can't see any reason why there needs to be any kind of custom script. If you want to upload the bat/vbs/ps1 file that is doing the actual work for the script it should be pretty easy to figure out what is going on.

I also ran into a problem like this with a client and it turned out to be the logon script and how it was sharing printers that was crippling the server. Are there any other custom scripts running on the system?

There's probably similar breakage here, it's not using the standard MSware to do the backups, and that's likely half the problem. I need to fully understand it before I can mess with it and/or replace it, though. I'll be taking a look tomorrow.

Dilly - I like that. The boss doesn't have admin rights, though.

Forge wrote:

..."The boss doesn't have admin rights, though. "...

Good choice , that can usually lead to some REALLY bad consequences.

Forge wrote:

You didn't read my first post, I'm guessing? The server itself CAME with a 2008 R2 license. What I don't have right now is the time to tear it down and put plain old 2008 R2 on there. I also can't have downtime on the server ATM, since we're on AD.

Yeah I missed the "CAME with" part. The time clarification is important. You're saying you don't have DOWNtime available at present, which makes sense, and makes my comment even less helpful. Sorry! On the other hand you did say "should I just get it swapped out for a 2008 R2 install ASAP?" which led me to believe you DO have time. I still think it would be worth it. Worst case, you're talking a 3-day weekend of downtime (for non-experts), or less than 1 day for people familiar with the process. If you had another box to replace it, your downtime could be limited to minutes.

Forge wrote:

I just need to make it run a little better in the meantime.

MSSQL is a good first target - it will consume ALL remaining available RAM, which means that any time another app wants some RAM, MSSQL has to release it first. I don't believe AD needs MSSQL to run, so you could potentially disable it in Services. That alone might change things significantly. If the backup script is such a hog, it sounds like its backing up each time there is a change :-/ I recommend it be disabled, and replaced with your own. I use automated Robocopy scripts which run once per day / week depending on the server. Obviously another way is to add a Software RAID and plug another drive in through ESATA or iSCSI.

At the end of the day, all of the tweaking might be considered "throw away" work if you're going to re-do the box anyway. Yes it could be "fun," but what about ROI?

No worries, jdl, I've made that mistake myself plenty of times, and should have been nicer about it, even for just that reason. Some more info, since it helps everyone help me; I'm currently doing dual duty as a phone-based CSR and also sole dedicated IT staff. It really cuts into my ability to do either job properly, but I have faith that this is being taken into account, above my level. Making the SBS machine run better would be a huge help to that, but I'm restrained by the existing setup. I can't make anything perceptibly "worse", even for a short time, because the negative feedback from that will overwhelm the promises of "better" that are my only currency at the moment.

Right now,suspect number 1 is the backup script. It more or less works, but not knowing anything about how it's working makes it a liability. Once I've got a better documented replacement in place, I'm planning to make my Exchange kill permanent, kill or restrain excess MS SQL (there are three right now, AFAICT, and I have a fully functional 2008 R2 AD on my VMware machine with zero SQL servers), and pare down/remove Sharepoint and other "never planning to use that" features. The mention of CALs gas me gun-shy of my original 2008 R2 reinstall plan, since I don't yet have any budget.

Big thank you to everyone in the thread. This has been a very fertile brainstorm/knowledge transfer, and I'll keep you all apprised of my progress (when I'm allowed to make some!)