August 2004 - Posts
This tip was recently offered on the SBS2003 public newsgroup (thanks R Stovall!):
Here is the definitive answer as far as I am concerned. I used to have all kinds of trouble with various clients and servers, but once I figured out the
sequence of commands I haven't had a single problem. Honest!
Run the following on the problem machine:
net time /querysntp (this will tell you what your currently configured time source is)
net stop w32time
net time \\(problem-machine) /setsntp:goodsntpservername (more than likely your PDC emulator)
net start w32time
Boom. Done. Happy as a clam!
PS You should be able to eliminate the \\(problem-machine) argument if running the commands locally, but the whole Windows time thing is flaky, and,
well, it doesn't hurt to be sure.
Mark Fulton posted recent issue with new SBS2003 installation. After installing Veritas BackupExec 9.1, he got a BSOD. Here's what he wrote for the resolution:
I have been using Veritas BackUp exec for some time on my Win2K network and with the installation of the SBS2003 forest/domain, I bought the new 9.1
version for SBS. Very cost effective, easy back up and restore of Exchange and SQL (including single message restore), etc.
After installation of 9.1 and reboot was I surprised with a 'Blue Screen of Death' (glad NOT to see too many of those anymore!). I was able to get
SBS2003 back up by choosing 'Last known good...' option from the F8 key press. DNS was initially muddled up but righted itself after a few moments.
Unfortunately, there is no free phone support for such a disaster (left Veritas customer support a word about that), but their e-mail response was
about one hour.
To make a long story short, if you are using a SCSI tape drive, you should see the document http://support.veritas.com/docs/261728 before installing
Backup Exec. Basically, there is a hotfix required from Microsoft (Q838894), and two fixes from Veritas (see the above link). Follow the directions and it
Hopefully, this will prevent the panic for someone!
To locate the Group Policy setting look in:
Administrative Templates - Network - Network Connections - Windows Firewall
I found that even though I changed these, the problem still persisted. I was forced to make a registry change that did the trick:
HKEY_LOCAL_MACHINE > SOFTWARE > Policies > Microsoft > WindowsFirewall
Then, in the Standard and Domain Profiles, change the EnableFirewall value to zero (0).
Thanks to Jonathan for providing these notes:
Installing MELL on a Microsoft SBS 2003 Server
Step 1: Follow the steps to install MELL on a web server as outlined in the Mell 2.x Deployment Guide located here:
Step 2: Once completed, you'll note that when trying to access MELL via http://servername/mell/eng, you get the following error:
006~ASP 0175~Disallowed Path Characters~The '..' characters are not allowed in the Path parameter for the MapPath method.
When attempting to access the reports via http://servername/mell/eng/reports, you'll get the following error (if 'Show
friendly HTTP error messages' is disabled in IE): Microsoft VBScript runtime error '800a01f4' Variable is undefined: 'Session' /mell/eng/reports/inc/reportfunctions.inc, line 987
To resolve both of these issues, open Internet Information Services Manager > (Start-->All Programs-->Administrative Tools--Internet Information Services > (IIS) Manager). Expand the server, expand the 'Web Sites' folder, and expand the 'Default Web Site'. Right-click on the folder named 'MELL', and select 'Properties'.
On the Virtual Directory tab, click on the 'Configuration' button. Go to the 'Options' tab. Turn on the 'Enable session state' and 'Enable parent paths' options by checking them. Click on OK twice.
Step 3: Restart Internet Information Services (Start-->Run-->'iisreset').
That's it! Hope that helps someone.
Doug Neal posted this informative look into the differences between Windows Update (WU) and Microsoft's Baseline Security Advisor (MBSA):
MBSA does one important thing that WU does not: MBSA will check explicit files to ensure a security bulletin and all of the associated files are patched on a machine. This is far and above the best way to ensure your machine is up-to-date for all security bulletins released by Microsoft. WU detection may result in incorrect patch status after uninstalling a patch, using System Restore on a machine or performing an in-place repair of the OS. Since MBSA checks explicit file versions, no matter what state a machine is in, MBSA will correctly detect whether a patch is sufficiently applied in a way that WU cannot.
Windows Update does one important thing that MBSA does not: WU will scan for all updates, not just security updates (which can include drivers, recommended updates and ‘nice to have’ features offered by Microsoft).
Aside from both of these traits, it’s important to understand one more aspect of MBSA 1.2. Although the current version of MBSA has added support for many OS features and components (such as MSJVM, MSXML and MDAC), there are still patches for which MBSA cannot report the status of a patch (such as Outlook Express, WSH [Windows Scripting Host], and Front Page Server Extensions). When MBSA encounters security bulletin information that the MBSA engine cannot scan for, MBSA will report a NOTE message. When MBSA encounters a security bulletin for a component or feature that is not supported by MBSA, there will be no message (no note, no warning – nothing). In both of these cases, it is an important indication that the administrator will need to check the details of this patch manually. These issues are covered more fully in the associated KB article 306460.
I hope that helps explain some of inner workings of MBSA in a way that helps
After installing Exchange SP1 on SBS2003, you may find that to login to OWA you will need to enter Domain\Userid format. Microsoft did release a fix to this and several other small problems. Check it out at:
Here's a link to a Microsoft KB article (233427) that identifies those files and folders that NTBackup does not include in the backup and restore process:
Here's how to change the default OWA graphic on the login page (tip of the hat to Jeff L.):
Just change the image at: exchweb/img/logon_logo.gif
Dimensions are 331 x 62
A question was asked “How can I change the SSL port# used to access OWA?“. This response was provided by Ray Fong (assuming we want to change the port# from 443 to 10001:
1. Go to Exchange System Manager, Protocols -> HTTP. Right-click New HTTP Virtual Server.
2. Specify "Exchange OWA 10001" for the name.
3. Click Advanced, modify, change the port from 80 to 81. SSL port is not available, that's OK.
4. After you click OK and Applied, go back to the same screen. Now remove port 81 and specify 10001 as the SSL port. Click OK all the way.
5. Follow the steps below to force the DS2MB replication.
a. Go to IIS, right-click servername (local computer), Properties. Backup/Restore Configuration to save a copy of IIS settings
b. Right-click servername (local computer), Properties. Check Enable Direct Metabase Edit.
c. Open MetaBase.xml with Notepad.
d. Locate the following object where ID = 61472
ID="61472" (<---- This one)
e. Change the Value to "0". Your original number will not be "53322".
f. Save the file.
g. From a command prompt, type "iisreset"
h. Restart Exchange System Attendant
6. Now, OWA is available via https://FQDN:10001
Microsoft SBS Product Support
Someone posted that Exchange was generating .log files at the rate of 3 per minute! Here's what Chad Gross responded:
Someone is sending a lot of mail through this server. First thing I would recommend is closing port 25 on the server to effectively disconnect Exchange from the internet.
Next, open Exchange System Manager | Servers | <servername> | Queues. If you have a slew of outbound queues, click the 'Disable Outbound Mail' button, then start cleaning up the Queues:
Highlight a Queue, click 'Find Messages', change 'Number of messages...' to 10000 and click 'Find Now'. Select all messages, right-click and select Delete (No NDR). Repeat for each rogue queue. When the queues are clean,
click to 'Enable Outbound Mail.'
Navigate to Servers | <servername> | Protocols | SMTP. Right-click on Default SMTP Virtual Server and select Properties. On the Access tab, click on the 'Relay' button. Remove the check mark from 'Allow all computers
which successfully authenticate to relay, regardless of the list above'. Click OK, click OK then close System Manager.
Finally, have all users change their passwords, and take this opportunity to reiterate the necessity of long, strong passwords. You've enabled password policies, right?
Chad A. Gross - SBS MVP