Not cleaning up log files? New client out of space on their SBS server, awaiting the swing migration budget approval? Check these posts out…
Also - if you've already disabled volume shadow copy, check on it and make sure it's not holding on to old snapshots unnecessarily. Open My Computer, right-click on the drive in question, go to shadow copies, and look at the "Used" column. If it reads some significant amount, and is disabled, click Settings, and change it to the minimum limit to clear out what's being stored and free up some capacity.Recently Chad talked about his reasons for moving off of ISA in SBS deployments, and replacing ISA with CheckPoint’s Safe@Office 500W. In the past, we’ve avoided ISA on SBS, standardizing instead on using the SnapGear (SG) product line for our client's perimeter security. Internally, the basis of this decision is rooted back in the SBS2000 timeframe, but ultimately is a result of the cost-benefit analysis of managing ISA, versus that of a perimeter appliance and the feature-set that our clients were requesting. In other words, ISA while “free” on SBS, and feature-rich in terms of what it can do, ended up being more than our clients tended to need, while the costs of change-management on ISA tended to exceed those of the SG-series that we were moving to standardize on.
None of this is to say that I don’t personally like ISA, nor do I consider it inherently insecure as some seem to. In fact, we’ve used it on a stand-alone box internally for some time, and have enjoyed the benefits that come with AD-integration, and web-publishing. So while our environment no longer precisely mirrors our client-environments (for a whole host of reasons), and I am a advocate of ISA – especially in mid-sized organizations, we’ve standardized on SnapGear for our SBS deployments.
Besides, Cougar is going to require something in front of SBS in the future. So we're either ahead of the curve, or just lucky.
Note: This isn’t specific to SBS, but larger organizations tend to already have processes in-place to handle this.
Short answer – use “redircmp.exe” for all of your SBS installs.
Need reasons? Read on…
So, by default when new computers get added to the domain, they get created in the Computers container. And it might be okay that they get dumped there because it forces someone to do something with it. Assuming you’re the only one managing it, you won’t forget, right? Oh, you might? What about you’re other netadmins, will they forget? Maybe so.
Simplify and automate…
That’s why we have Active Directory anyway, right? Well, that and to scale nicely – but doing stuff is a big part of it. So if you have computers piling up in that computer container (by now you should have opened out ADUC), then you know for a fact that they don’t get any GPO’s applied. And if dozens of boxes – for that matter, if even a few boxes – have been added without following the correct process, then at best you have some confusion. Worst-case, you have boxes that aren’t getting updates distributed via WSUS (or some similar fate).
Fortunately, there’s a tool for this called “redircmp.exe”. What it is? How do you use it? Is it safe for SBS? Don’t want to read the KB article? Well, it’s just what it sounds like – a tool for redirecting the default location of newly created computer objects (there’s a “redirusr.exe” too, which does the same for users). The first step is to probably to consider building onto the OU design of SBS. No, I’m not talking about changes to the SBS-ized stuff… we tend to build-out beneath the default OU structure for customization. Why? Well, it reduces risk - it helps us to enable our clients to do a bit of self-management sometimes – and it keeps team members from making big mistakes. But the main reason is that you probably want something that makes sense for your circumstances and your client. The hierarchy should fit the business-need.
As far as how to use it, there’s not much to it… from the SBS server just run it and it gives you the usage. Otherwise, here’s something that might make sense for you… obviously this is a sample based loosely on the SBS hierarchy.“redircmp ou=WSUSMasterOU,ou=SBSComputers,ou=Computers,ou=MyBusiness,dc=domain,dc=local”
It should respond with “Redirection was successful.” If it said something else, check this KB article. Now go ahead and test it. Fire up Virtual PC with a base-image, add it to the domain, and refresh the OU in ADUC. It should show up down in the WSUSMasterOU (or whatever is appropriate for you). Depending on how much automation you want, this might be enough. At the very least, you're a step in the right direction – and if someone is forgetting to move it down further into the right OU, or add it to the right group, then at least you’ve got a base level of GPO’s being applied.
I started writing a post about how to enable and manage Exchange Mobile Messaging – also known as DirectPush – when I found a really good series of articles written by Henrik Walther. It’s too bad they weren’t available when we were putting together our SBS client deployment process last year as they’re great time savers. So, instead of reinventing the wheel, I’ll just give the high-level overview with some SBS tips, and then refer you to his articles for deployment details.
What is Exchange Mobile Messaging?
Commonly referred to as DirectPush (or always-up-to-date; AUTD v2), Exchange 2003 Mobile Messaging enables your Windows Mobile clients (i.e. smartphones) to synchronize their mailboxes (specifically - Calendar, Contacts, Tasks, and Inbox) over-the-air (OTA).
What do I need to know to make this happen?
Isn’t this difficult to accomplish on SBS? I’ve heard there are certificate problems.
Assuming you have Exchange SP2 installed - It’s not very difficult. If you’re using self-signed certificates, you might run into a few snags. Obviously, a certificate from a trusted certificate authority will make this easier - some phones don’t like the self-signed certificates. However, we’ve been able to get self-signed certificates working on Samsing Blackjack (Cingular), and Treo 700 (Verizon) phones without issue.
Specifically, I’m referring to the SMTP Connector in SBS 2003 (Exchange 2003). You’ll find this option in the CEICW wizard – or the SMTP connector (ESM>Connectors>SmallBusiness SMTP Connector Properties).
I prefer to use DNS, but I’ll explain more below. I think the key take away is that if you’re deploying SBS servers in client-environments, then you should really have a process in-place to ensure quality and uniformity across the environments that you support. Certainly, there are a few specific circumstances where you probably need deviate from the “standard”, but these should be the exception and not the rule.
So why use DNS? I actually think the case for why you should not use the ISP/SmartHosts is a better argument. For instance, if you’re forwarding though the ISP email originating from your organization will show that it was forwarded though the ISP in the header. Secondly, since UCE/spam also uses this method, it increases the likelihood of the mail not being delivered, and some domains refuse to accept mail that has been passed though a mail forwarder. There are more reasons too… maybe your ISP gets added to a RBL – and suddenly you’re blocked by extension.
In any case – I prefer to use DNS. What’s more, our SBS deployment process is to specify DNS. What’s your process look like?
So we all know that Out-of-Office auto responses are disabled for internet-bound email by default beginning with Exchange 2000, right? As with so many things - SBS behaves the same way, and with good reason. By default, out-of-office messages don’t ever make it out of your organization.
This is a good thing.
If you disagree, you can change this behavior by following KB262352. But don’t.
Let’s talk about why the default behavior is a good thing.
Say that you’re out-of-the-office, you’ve followed KB262352 and enabled the out-of-office responses for internet bound messages. But, like many in the SMB marketplace, you’re not on-board with a good enterprise uce/spam filtering solution, or hosted filtering service (and even if you are, I still don’t recommend changing the default behavior).
Here is what can happen:
1) You enable out-of-office responses
2) You start receiving messages - and like everyone else, you get some uce/junk mail.
3) Exchange now doesn’t care if it’s junk or not, or where it originated… it creates a new message grabbing the “From:” address from the junk message, and sending it out.
4) The “From:” address probably is spoofed (you can check the message headers to confirm this), so you’re probably sending your out-of-office response to an unsuspecting person.
5) Now, this person might not exist, or might have a full mailbox, or might be confused as to why you sent them message to begin with… so they reply. And they get another out-of-office response.
And so on.
So multiply that by the number of messages you get, and you begin to see the problem.
This is a bad thing… even on an SBS 2003 server with only moderate usage.
So while you can enable out-of-office responses, you probably shouldn’t.
Okay, then… I don’t get it. I’ve read the posts, I’ve looked at the changes in SBS 2003 R2, and I just don’t get what the fuss is all about. So it’s an updated release of SBS 2003 with some new features… some good, maybe some bad… but mostly relevant updates… I’ll do the same thing with R2 as I did with SBS2003.
It’s important to me that we convert the remaining SBS2000 customers to R2. Just like it was important when we converted those still on SBS4.5/NT4 to SBS2003. There’s always going to be customers that are a generation behind mainstream… and if they’re good customers, I’m not going to send them to competitors just because they’re slow to change (now if they don’t pay, that’s a different story).
I think planting the seed is important, because even if they decide not to upgrade today, they’re going to remember something about it during the next cycle. And as long as you’ve earned a spot as a trusted advisor, they’re going to remember (maybe with some prompting) that upgrade/replacement was talked this during the last cycle, and that they should give some serious consideration this time around.
The SMB market might not be the enterprise, but just because our customers work with smaller budgets, doesn't mean that we don't have a need for reliable service, and supporable hardware.
So I had a customer call that was very concerned about the MTA service being disabled in SBS 2003. I'm not really sure how they arrived at their concern, nor were they interested in explaining what prompted the conversation, but they wanted to know why the service was disabled.
Long-story short, on SBS 2003 the MTA stacks serivce is disabled by default. You can leave it that way unless you have a specific need.
Since I’ve been tending to do a lot of SBS posts lately, I just thought I’d just follow-up on my last post by confirming that SBS 2003 can only support up to 4GB of physical memory, being that it’s built on Windows 2003 Server Standard edition.
