Exchange 2003 End-of-Life? Fix it today.

Two business days until Exchange 2003 goes end-of-life.  Two more days until you need to need to be upgrade.  Whether you work for an MSP, or you've been trying to get your boss to move off of Exchange 2003 or the past decade, you're quickly running out of time.  That being said... I get it... if you haven't upgraded yet, it's unlikely that you're going to next week.  But sooner or later, you're going to wish you had.  And when you do, would't it be nice if you had a goto plan that's already been put through it's paces?  A plan that's already been used in real customer environments... everything from SBS 2003 to the Enterprise.  Wouldn't it be nice if you could just execute the plan?  Without buying an Exchange book, learning everything about an application that you don't even like... and wouldn't it be nice if you knew it was going to just work.  Well, this is the kit you've been looking for.

I just moved my final SBS 2003 client off of Exchange 2003 last week.  Yes, that's right.  After years of recommending, suggesting, and imploring... they bought it.  And using the kit I did it with a minimum of pre-planning, one scheduled reboot of the SBS 2003 server, and a bulk mail move of all of their accounts - I was finished by 4:00pm on Friday.  No late nights, no angry clients, and no annoying ActiveSync problems.  On top of that, I sold it as a fixed-cost, basing the project on a 40 hour gig, and it took two days total effort.  How's that for a fixed cost no-brainier?

Buy the Exchange end-of-life kit today for $73 and with 1-2 days of total effort, you can do what normally would take a week.  How's that for a good fixed cost margin?  On top of that, it's no stress, no lost weekends, and most importantly - a happy client.  Our kit works, because we've been using it, and continuously improving for years.

Replacing SBS self-signed certificates with 3rd party SSL certificates

Just because this question comes up more often than it should...

http://blogs.technet.com/sbs/archive/2007/08/21/how-to-install-a-public-3rd-party-ssl-certificate-on-iis-on-sbs-2003.aspx

SBS: Are you redirecting the location of newly created computer objects?

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.

Scripts: Why more SBSers should be writing scripts!

Right to the point…

More SBSers should be writing scripts!

In the past I’ve posted snippets from a number of scripts that I’ve written… from checking Antivirus definition dates, to detecting Virtual Servers, to calculating free space, to querying for FSMO roles… (all right, so that last one isn’t exactly a common need for the average SBSer). But in case I haven’t made it abundantly clear already…

Scripting rocks!

Now I know what you’re thinking, and I’ve heard the excuses, scripting is… too hard, too time consuming, or even the wrong tool for the job in the SBS world. If that sounds anything like you, then let me let you in on a little secret... you don’t have to be a programmer to write useful scripts. You don’t even have to do it on a regular basis… you just need some exposure! Personally, between the stuff that I’ve already written and the community resources that are available, I don’t have to re-invent the wheel very often.

What I like to do is start with something simple, and write a small single-purpose script. Then maybe a few weeks later I come across another need, and write another single-purpose script to handle that task. After doing so, I’ll combine both of those scripts to handle some more complicated task. And that’s how my tool kit grows… I keep writing these little one-off scripts, and incorporating them as subs or functions into more complicated tools. It all keeps building.

Now go and get started… look at what’s available on the Scriptcenter, find something that you want to be able to do… maybe you want to bounce the Print Spooler, or something like that… then mash a few of their scripts together until they do more useful things for you. After you’ve done that… start tweaking… write another script to email you when an event happens… then add that email script as a sub or a function to the script that you created to bounce the print spooler… and just keep growing your tool set.

Remember, you don’t have to be a programmer, and you don’t have to crank out new scripts every day to add-value. Scripting is just another useful tool in your arsenal.

Group Policy: Why aren't more SBSers using Group Policy for stuff?

One thing that I see going way underutilized in the SBS world is group policy.

And no – I’m not counting what’s pre-configured to automagically “just work” in SBS. I’m talking about leveraging group policy to deploy your apps, utils, and other updates –whenever possible.

So the reason that I was reminded of this today, is because I was working with a large customer who needed to deploy a Citrix ICA client to a bunch of systems. I was talking to my SBS admins who were throwing out ideas like… scripting it, RDP/TS into individual systems, etc. And I was just beside myself because, well… Group Policy rocks! Deploying a tool like the ICA client to oh… two hundred systems with almost zero effort is a blast! Besides, why would I want to make this more difficult than it needs to?

So I was thinking… perhaps SBSers are intimidated by Group Policy… could that be? I don’t know... tag that as SBS-intimidation... because if they are, then they need to start hitting the lab more often. In fact… they better have just been too scared or lazy today because dang it, group policy shouldn’t just be overlooked!

Use the tools we have… especially when they're powerful, and free!

Oh, and if you’re on SBS… and you want scope some GPOs, I recommend adding OU’s below what’s pre-configured in SBS. Don’t muck with the SBS OU’s unnecessarily. It’s just not a good idea – especially if you’re not sure what you’re doing!

SBS2003: Renaming the "CompanyWeb" in SBS

Well, maybe not rename exactly, but at least get it to respond to “http://whateveryouwant/”. The reason we’re not actually renaming companyweb is because it breaks-stuff – to much stuff to readily fix, as SBS references companyweb in a lot of different places.

So to start with, open up DNS manager (run command, “dnsmgmt.msc”) and take a look at the existing “CNAME” alias for “companyweb”. Using this as a template, create a new CNAME alias called WhateverYouWant, making sure that the FQDN is WhateverYouWant.domain.local, and that the target host points to your SBS server (servername.domain.local).

Finally go into IIS and right-click and select properties on the CompanyWeb, and add a host header for WhateverYouWant and WhateverYouWant.domain.local. Stop and restart your CompanyWeb in IIS. Then launch a web browser and point it at http://whateveryouwant/ and the companyweb will respond.

Keep in mind that http://companyweb/ will still work, but if you’d prefer something else, like say http://intranet/ or something that makes more sense for your organization, then this will work nicely.

SBS: Accepting mail for multiple domains

When a customer claimed that one of our competitors (who we were bidding against us for a project) informed them that one of the downsides of using SBS was that you couldn’t host email for multiple domains, we needed to explain to the customer (gently) that in fact you could add multiple domains to SBS without issue. Contained below is a procedure for doing just that.

For Exchange 2000/2003, and SBS 2000/2003

1) Open Exchange System Manager
2) Expand Recipient Policies, and right-click on the Default Policy
3) Select the “E-Mail Addresses (Policy)” tab
4) Click the “New” button, select “SMTP Address” and click ok.
5) In the “Address:” field, type “@yourdomain.com”, leaving checked the checkbox indicating that “This exchange organization is responsible for all mail delivery to this address” (Click here for more information on authoritative and non-authoritative domains).
6) If this is going to be your new primary domain, you can choose to “Set as Primary”.

Finally, keep in mind that if you’re adding a new domain, you need to add an appropriate MX record for this new domain to DNS (typically done though an administrative interface, provided by your registrar or web host).

SBS compromise response

This must be an on-going debate over the “SBS compromise” because I’ve heard it frequently… and perhaps there are a few other places where this hits closer to home than in the organization I work for… but not many. As a matter of function, I tend to have one foot in the enterprise, and one foot in the SMB market. So yes, I can appreciate first hand how SBS tends to end up being the punch line instead of the solution.

Among the enterprise circles of the IT community, I think Chad is correct. Assuming the enterprise admin you’re talking to even knows of SBS, they’re probably going to hate it. “A DC, Exchange, ISA, RRAS, IIS, Tape backup… etc… all on one box… [insert punch-line here]”… I know, I’ve heard it. Heck, when I was first introduced to the SBS platform, I had a similar position.

But now, a few years out, I have a whole new appreciation for SBS. Why? Because SBS is the right tool for the right job.

“What do you mean, right tool – look at the security issues!”

Yeah, I know… just look at them. You know what the small business owners I talk to think about “security”? They demand it… that is, they demand it until they start to get an understanding of the cost/benefit. When we start talking about dedicated purpose servers… servers, which I might add, that are going to run at about 1% utilization on a busy day. And then we talk about licensing. And then we talk about firmware maintenance… and then the patch management lifecycle on each of these boxes… you get the idea. That somewhat reasonable 10k-15k initial investment for a complete SBS-solution, all of a sudden turns into something literally impossible for your average SMB-sized customers. And if by some chance you were to get an SMB customer to buyoff on your “secure” dedicated server solution, how do you think they’re going to pay to maintain it? So when no one has patched those boxes in two years, how secure do you think they’re going to be?

For your average SMB customer, you need to understand what you’re trying to protect. For the most part, they’re not banks, or financial institutions… you’ll see some HIPAA compliance issues, and a few with some type of trade-secrets. But at the end of the day, you’re trying to come up with an acceptable cost/benefit for the customer. Understand the need for security, but appreciate the fact that if they need some type of IT infrastructure, an SBS solution beats paper, or a workgroup hands-down.

SBS, Healthmon: Article 6, Specific items to monitor for using healthmon

Without giving away our edge here, I wanted to document a few of the healthmon alerts that I like to use, and alluded to in the previous five SBS healthmon posts (linked below). This is by no means exhaustive or comprehensive, but using commonsense, you can start to see some of the real value you can add by leveraging healthmon in your offerings. And remember, this is all out-of-the-box type functionality, and the key is that it provides real business-value.

Why did that server go down over the weekend? Are my backupexec remote agents running? When was that computer account created, and why? Who created that user account?

In the enterprise, these items would be covered and then documented as part of a change management process. In any environment, these are really key building blocks in establishing a “managed services model”.

So, listed below are a few of the alerts I use, as well as the relevant alert configurations. Each one has a justification section explaining why they’re being used. Take a look. If you have something you’re using effectively, why don’t you go ahead and add a comment to that effect?

Type: Core server alert, Data Collector>Service Monitor
Name: SBS Server, BackupExec Remote Agent
Details, Service: BackupExecAgentAccelerator
Details, Properties: Display Name, Started, State, Status,
Actions: Send Email>Execution condition, Critical>Reminder:6 hours
Message: standard service monitor message (state and condition), plus server name.

Justification: Alert sysadmin when the Veritas Backup Exec remote agent service on the SBS 2003 server fails. The “backup server” is located on another machine.

Type: Core server alert, Data Collector>Windows Event Log monitor
Name: SBS - Computer Account Created (645)
Details: Success audit
Details, log file: Security
Details, Event ID: 645
Actions: Warning, and Critical email
Schedule: all days, all times, every 1 second, 1 sample needed
Message: Computer account created

Justification: Alert sysadmin whenever a computer account gets created. Computer accounts created by non-admin’s need to be reviewed for security compliance (a/v, patch, OS, etc).

Type: Core server alert, Data Collector>Windows Event Log monitor
Name: SBS - Computer Account Deleted (647)
Details: Success audit
Details, log file: Security
Details, Event ID: 647
Actions: Warning, and Critical email
Schedule: all days, all times, every 1 second, 1 sample needed
Message: Computer account deleted

Justification: Alert sysadmin whenever a computer account gets deleted. Computer accounts typically shouldn’t be deleted by non-technical owners and sysadmins should be alerted to review the issue.

Type: Core server alert, Data Collector>Windows Event Log monitor
Name: SBS - User Account Created (624)
Details: Success audit
Details, log file: Security
Details, Event ID: 624
Actions: Warning, and Critical email
Schedule: all days, all times, every 1 second, 1 sample needed
Message: User account created

Justification: Alert sysadmin whenever a user account gets created. User accounts typically shouldn’t be deleted by non-technical owners and sysadmins should be alerted to review the need/assignment of the account and account properties.

Type: Core server alert, Data Collector>Windows Event Log monitor
Name: SBS - User Account Deleted (630)
Details: Success audit
Details, log file: Security
Details, Event ID: 630
Actions: Warning, and Critical email
Schedule: all days, all times, every 1 second, 1 sample needed
Message: User account deleted

Justification: Alert sysadmin whenever a user account gets deleted. User accounts typically shouldn’t be deleted by non-technical owners and sysadmins should be alerted to review the change.

Type: Core server alert, Data Collector>Windows Event Log monitor
Name: SBS - Failed Password Attempt (529)
Details: Success audit, Failure audit
Details, log file: Security
Details, Event ID: 529
Actions: Critical email
Schedule: all days, all times, every 1 second, 1 sample needed
Message: User account deleted

Justification: Excessive failed password attempts should be reported to a sysadmin for event follow-up.

Name: Member Server – Server-Name (no-ups) Ping (ICMP) Monitor
Details: System, “server-name”, timeout(msec): 1000
Actions: Critical email
Details: Success audit, Failure audit
Details, log file: Security
Details, Event ID: 529
Actions:
Schedule: all days, all times, every 10 minutes, 6 samples needed
Message: Server-name down: Ping failed (power-issue?)

Justification: For servers that do not have a UPS attached, downtime should be recorded and reported to a sysadmin as justification for possible purchase (non-sbsers probably won’t get this one).

Previous 5 SBS, Healthmon articles in order of posting:
SBS: "sbsmonacct" and healthmon alerts
SBS Healthmon: Filtering events for notification
SBS, Healthmon: Why would I care about notifications?
SBS, Healthmon: Why would I care when a computer account gets created/deleted?
The managed services model

SBS, Healthmon: Why would I care when a computer account gets created/deleted?

So you’ve read the previous few posts, and you’re a little interested in using healthmon. But maybe you’re just not yet to the point of actually doing anything about it. You’re probably sitting there asking yourself, “Hey, great, so I can tell when my customers are adding computers. Why should I care?”

You should care because you’re a driven professional who takes pride in your work. And depending on the type of contracts you’ve been able to secure, you should start getting preventative, and take technical ownership of the installations (obviously to the extent that your customer has directed). Beyond that, you should care because you want to add value. Remember that you’re there to protect the customer’s IT infrastructure, and sometimes that means protecting it from the customer.

It’s great when a customer is technical enough to add their own computers to the domain. But it’s not so great when those systems are added without considering the workstation lifecycle. How are those systems going to get updates from the WSUS server? Who’s responsible when they’re not added to the managed antivirus installation? Who’s accepting these risks, and the costs associated with them.

Obviously, there’s still a healthy balance to mind, because you and I both know the customer is not going to perceive any value from you bugging them to update the BIOS revisions on their workstations every few months.

Mind that healthy balance, and focus on adding real value.

Additional resources:
sbsmonacct notifications:
Filtering Events using SBS Healthmon:

SBS, Healthmon: Why would I care about notifications?

So you’ve read the previous few posts, and you’re a little interested in using healthmon. But maybe you’re just not yet to the point of actually doing anything about it. You’re probably sitting there asking yourself, “Hey, great, so I can tell when my customers are adding computers. Why should I care?”

You should care because you’re a driven professional who takes pride in your work. And depending on the type of contracts you’ve been able to secure, you should start getting preventative, and take technical ownership of the installations (obviously to the extent that your customer has directed). Beyond that, you should care because you want to add value. Remember that you’re there to protect the customer’s IT infrastructure, and sometimes that means protecting it from the customer.

It’s great when a customer is technical enough to add their own computers to the domain. But it’s not so great when those systems are added without considering the workstation lifecycle. How are those systems going to get updates from the WSUS server? Who’s responsible when they’re not added to the managed antivirus installation? Who’s accepting these risks, and the costs associated with them.

Obviously, there’s still a healthy balance to mind, because you and I both know the customer is not going to perceive any value from you bugging them to update the BIOS revisions on their workstations every few months.

Mind that healthy balance, and focus on adding real value.

SBS: Thoughts on patch validation

I'm going to have to agree with Nick Whittome on this, in his response to Susan's post about the world of SBS consultants. While I probably sit closer to the "V's" side of the discussion than that other Nick ;) , I really believe that consultants - especially SBS consultants have to do both. Sometimes they're going be a "~'s", and other times, they're going to be "V's" (if this sentence doesn't make any sense to you, check this link) . In fact, there are times when they're going to be in both camps, depending on the customer that they're serving.

Whoa! Wait a second, what? Yes, that's right.

Every customer is unique.

Even if your customer systems are virtually identical (and even among SBS installs, you'd have a hard time convincing me of that), you have to treat each situation as though it's something new. Now, granted, you're going to be a little more confident after deploying 2003 SP1 (or whatever) on your tenth SBS install, than you will be on the first. But that doesn't mean you shouldn't take the same precautions as you did during the first three installs. And if you're not putting the effort into things, than, at least in my opinion, you're doing your customer a real disservice! And you're also doing your employer a disservice by leaving potential revenue "on the table".

That being said, I have to live in the real world too. There are situations where you're not going to have the opportunity to "do the right thing", when it comes to testing and validation. Some customers just aren't going to pay for that effort.

When that happens, it's good to keep in mind that all of your customers are important. Just don't put the best ones at risk dogfooding/testing/validating when you could be using your less-than-best customers for the validation effort.

So, to bottom-line it for the consultants out there... Don't take shortcuts. It puts your customer at risk, and it impacts your revenue streams. Oh yeah, and make sure the people paying the lion-share the bills are getting the benefits!

SBS Healthmon: Filtering events for notification

To follow-up on yesterday’s post, I wanted to add some details on using healthmon.

To begin with, let’s just start by opening healthmon on your SBS2003 machine (start>programs>administrative tools>Health Monitor). Expand the “Small Business Server Alerts” object. Here you’ll find all of the current alerts that come pre-configured on your SBS machine.

This is where data collection for alert notifications is setup. So if you’re already receiving the occasional “Extended Server Usage Report for…”, message, then you’re good to go. If not, then you need to go back and configure “Monitoring and Reporting” under the SBS 2003 “Server Management” snap-in.

Next, let’s go ahead and create alerts to monitor the creation and deletion of computer accounts.

While in healthmon, right-click “Core Server Alerts”, click New, data collector, windows event log monitor. Click the details tab. Put a check-box in “Success Audit”. For the log file, choose “Security”. Under event ID, type “645”. Click the Actions tab, and create a new email alert. Under execute condition, check the “Warning” and “Critical” checkboxes. Under schedule, make sure all days are selected, and all times are selected. For collection interval, collect every “1” second, and total samples for collection, set it to “1”. Under the “Message” tab, in the section that says “when status changes to Critical or Warning” type “Computer Account Created”.

Great, so now an alert will fire whenever a computer account gets created. But what about when one gets deleted? Follow the same process outlined above; expect you’ll be looking for event “647”.

Expect some more follow-up and healthmon-related posts, including events that we monitor for, and our monitoring-approach for the small-to-midsized market segment.

SBS: "sbsmonacct" and healthmon alerts

For those of you that are old hats at the SBS support thing, you’ve probably long since ran across, and forgotten about the creation and deletion of the “sbsmonacct” account in the security log (filter for event ID 624 and/or 630; 4:30am-ish). I recall seeing this *way back* when I was first taking a look at SBS 2003. Having noticed it, I promptly filed it away for future reference.

Interestingly enough, I came across it again over the weekend after adding some monitoring alerts in healthmon to a customer’s installation on Friday. In checking my email on Saturday, I noticed that I had some account creation/deletion notices that had been fired off. Having since logged in to evaluate this, I was able to determine that this was expected behavior.

That, and… my alerts are firing nicely.

SBS 2003: SMTP Queue length follow-up

I received a follow-up question about the SMTP queue length post from last week.

The question was... "I followed the instructions in the SMTP server remote queue length post, but I just received a another alert... ?"

After following the instructions, go ahead an check your queue... there probably are still a number of messages that need to be flushed out. Just give it some time (or delete the items from the queue), and everything should clear up. If you're still having problems after waiting/deleting junk from the queue, you might have missed a step in the article.

Go head and look though the article again. I just referred back to my post to help out a customer, and everything seemed to work as expected. But certainly let me know if I overlooked something.

SBS 2003: SMTP Server Remote Queue Length Alert

Have you been getting the following notification from an SBS 2003 server?

“SMTP Server Remote Queue Length Alert on SERVER”… “A large number of messages are pending in the e-mail server send queue.”?

To start off with, make certain that your internet connection is up, and that it’s not a momentary outage from you ISP. Okay, so assuming that your internet connection is good, in all likelihood the solution will probably be to filter out recipients not in Active Directory (which is explained below). But before we turn that on, let’s just entertain for a moment that a weak password has been compromised, and that a spammer might be relaying using that account (hey, here’s another good argument for password complexity requirements).

So let’s go ahead and enable maximum logging on the SMTP protocol. Later you can sort though the application log in Event Viewer for event ID 1708, and determine if an account is being authenticated against using a weak-password for the purpose of relaying UCE/Spam.

To enable logging on SMTP, open Exchange System Manager (ESM), expand servers, and right-click on SERVER (where “server” is the name of your server). Select the “Diagnostics Logging” tab, then under services select “Exchange Transport”, and in the right-hand categories column, select “SMTP Protocol” and for the logging-level choose “maximum”.

The next thing that you’ll want to consider doing (possibly after getting a good sample of data via SMTP logging above) is to prevent Exchange from trying to process email for users that don’t have an account in Active Directory. In other words, Exchange will bounce email at the SMTP level for email being sent to users that don’t have an account on your system. This is a short two-step process, and should go a long way toward eliminating the SMTP Server Remote Queue Length issue you’re getting.

1) Open ESM, click Global Settings, Message Delivers, the Recipient Filtering tab, and check the box to enable “Filter Recipients who are not in the directory”.

2) Next, you’ll need to enable this on the SMTP virtual server in order for it to take effect. While you’re in ESM, click Servers, then SERVER (the name of your server), then Protocols, then SMTP, right-click on Default SMTP Virtual Server, click Advanced, click Edit on “all unassigned”, and enable “Apply Recipient Filter”.

This usually does the trick… in larger environments, I tend not to see this… Or at the very least, there have been some discussions in the Exchange admin group as to how to handle this. More often than not, I see it come up in SBS installations. Of course, be sure and keep an eye on things over the course of the next few days, and make sure that the issue really has been resolved. You also might want to disable the “maximum SMTP logging” that we turned on at the beginning, as over time you’ll start filling your application log up.

As a recommended follow-up, it might be a good time to mention the value of installing and configuring IMF to your customer – it’s quite a powerful “free” solution that you can start using immediately in an SBS 2003 installation. This will have a noticeable, and immediate impact for you customer - and it sure beats spending $2000 on a dedicated anti-spam appliance for perimeter filtering.

Exchange: Thank you mailbox migration wizard!

Hey, just wanted to give a big thank you to the team responsible for the Exchange mailbox migration wizard. I can’t tell you just how nice it is when a mailbox migration goes right.

Not that I expect problems, and with a fully tested migration plan that includes contingency planning you really should already know what’s going to happen before it happens. But it’s just a great feeling when things go off without a hitch! The customer is happy, I'm happy, and things get accomplished under budget and ahead of schedule.

I’ve performed mail migrations using the ESM method, Exmerge, and the Mailbox migration wizard (and in some cases a combination of methods : ) … and just have to just say how nice it is when things work out well.

XGen: Exchange Tools for migration
http://support.microsoft.com/default.aspx?scid=kb;en-us;281584

How to use the Exchange Migration Wizard to migrate mailboxes from an Exchange organization
http://support.microsoft.com/default.aspx?scid=kb;en-us;328871

SBS, Exchange, and Circular Logging:

So what’s the deal with Circular logging, and how does this apply to the SBS 2003 world?

First of all, there are quite a number of resources available on the Microsoft Knowledge base that relate to this topic. The problem is that if you read enough of them, you’ll probably end up just as confused as when you started. So let me try and make some sense of this for you.

You might notice that on a fresh install of SBS 2003, that circular logging is actually enabled (and stays that way until you run the backup-wizard). Contrast this to Exchange 2000/2003 Standard or Enterprise, where circular logging is disabled. Why the discrepancy? Probably because enough people called up product support services complaining that they were out of drive space, and that upon further investigation, support determined that they were out of drive space because they were hanging onto all of those transaction logs.

So what is circular logging? Well, it’s basically a log-recycler. After Exchange fills up the first 4 logs, circular logging assumes that it’s okay to start re-writing the first one. So you can see the problem – circular logging sacrifices redundancy in order to preserve drive space. This also breaks differential and incremental backup procedures. So you’ll have to do full backups.

What should you do?

At the very least, use the SBS-supplied wizard-interface to NTbackup. And make sure you are actually getting good backups. Do test restores as part of your Exchange maintenance policy.

What do I recommend?

I recommend Veritas Backup Exec. If you’re in the SBS world, Veritas makes a version specific to SBS, which includes an Exchange agent at a reasonable price ($437 for as of 7/05). You can search for manufacturer part number “A130478-0LB000”. But keep in mind that this will only let you backup your SBS server. You can’t purchase additional agents to backup any member servers that you might have in your environment. So if you have any member servers in your SBS environment that you need to backup (and you should be backing these up), you’ll probably need to get the full version of Backup Exec (which is quite expensive).

How to turn-off circular logging:
http://support.microsoft.com/default.aspx?scid=kb;en-us;314605

Re: Okay let's duke it out... One nic or two?

This is written in responce to Susan's recent post on 1-NIC or 2-NICs in an SBS install.

As an SBS consultant, your biggest responsibility is conveying risk. At the end of the day, it's your customer's decision, your customer's data, and your customer's business that is at risk. So if you're out there accepting risk on behalf of the customer, without informing them of key decisions, you're simply not doing your job.

1 NIC or 2? I think it depends on your customer. Look at their environment, look at the budget, and then try to balance the needs of the customer with the needs of your employer. Customers are brining you in to help navigate confusing decisions on their behalf, and at the same time are trusting you to keep them in the loop on decisions that can have a material impact to their business. Beyond that, your employer is in business to make money. You can't risk loosing customers because you don't want to implement a 1 NIC install that is "less secure". And you typically shouldn't look at new installs from a break-even perspective. In most SBS environments that I've worked in, there's just not allot of money to throw around on high-end hardware. If you can do a 2-NIC install on a better platform great! But if the choice is between a 2-NIC install, and you/your employer making money, you've got to make money first to stay in business.

So bottom line... Actively communicate risk to your customer, balance the needs of your employer with the needs of your customer, and always protect your profit margin. After you take care of those things, then you can worry about the details.