Aimless Ramblings from a Blithering Lunatic . . .

Just another Microsoft MVPs site

Category: 577

Specifying a Custom Port for SmartHost Communications in SBS 2008

Just this morning I helped a partner with this very scenario.  Unlike previous versions of Exchange, Exchange 2007 does not provide an interface within its management GUI to specify a custom port when using a SmartHost for outbound mail delivery.  As a result, we need to set this via the Exchange Management Shell.

Once you open the Exchange Management Shell, one simple command will allow you to specify the custom port to use:

set-sendconnector –identity ‘[Send Connector Identity]’ –port [Port Number]

In SBS 2008, the default Send Connector that gets created is named “Windows SBS Internet Send [SERVER]”  where [SERVER] is the netbios name of your SBS server.  So for example, if your SBS box was named  SERVER01 and you needed to use port 2525 to send email to your smart host, you would enter:

set-sendconnector –identity ‘Windows SBS Internet Send SERVER01’ –port 2525

If necessary, you can find the identity (name) of your Send Connector(s) from the Exchange Management GUI, or from the Exchange Management Shell.

In the GUI, expand Organization Information, select Hub Transport, then click on the Send Connectors tab.

In the Exchange Management Shell, run the   get-sendconnector   cmdlet to get a list of send connectors.

The View from the Dark Side

I have a confession . . .   I took my first step moving to the dark side three months ago.  You see, my beloved Treo 700w had finally died for the last time – it had lived a long, hard life of just over 2 years and had been dropped countless times.  I was looking for a Windows Mobile 6 device that had a touch-screen and a vertical orientation like the Treo (I for one dislike the slide-out keyboards because it requires two hands to type).  I was surprised at the lack of options available for those three criteria.  As a matter of fact – Verizon did not have a single device that met all three criteria – they still had the Treo 700w with a touch screen, but running WM5.  They had the new Moto Q with WM6 and the vertical orientation, but no touch-screen.  Or the Samsung isomething that had a touch screen and WM6, but had the horizontal slide-out keyboard.

So on a whim, I did an abrupt face and bought myself an iPhone.  This was back in March, and I admit that what finally pushed me over the edge was the announcement of the iPhone 2.0 software update that would include support for push email via Microsoft ExchangeSync.  Admittedly, there are days that I still miss my Treo  (I still prefer a physical keyboard over the iPhone’s on-screen keyboard – but I eventually discovered the trick to fast composition on the iPhone is to just get close and trust its auto-correct to fix your typos – and 98% of the time it gets it right).  The biggest pain over the past 3 and half months has been the lack of over-the-air calendar and contact sync.  After having that for over two years with my Treo, having to dock my iPhone every few days or remember to look at my Outlook calendar before I ran out the door was getting old. 

But anyway, today was d-day – when the iPhone 2.0 upgrade was officially available to the masses.  I didn’t get a chance to really try the upgrade until late this afternoon.  I started earlier this morning, but I could not get iTunes to backup my phone prior to the upgrade (unknown error -43).  Of course, it gave me the option to continue without a backup – I would just lose little things like my text messages, favorites, mail accounts, etc. – basically anything that wasn’t sync’d with my PC.  So I stuck it out and eventually tracked the issue down to iTunes not playing nicely with folder redirection in a domain environment.  My music lives in a redirected folder and syncs ok, so I’m assuming the issue is with a redirected Application Data folder.  But anyway . . . )   So late this afternoon I finally got the phone backed up and initiated the upgrade.  The entire process took about 30 minutes to download, install, restore & activate.  Luckily, I did not run in to the mess this morning where Apple’s activation servers were overwhelmed and couldn’t be contacted, leaving a lot of people with a nicely upgraded phone that could not activate and thus had no service . . .   but again, there’s a reason it’s called the bleeding edge . . . smile_regular

But the big news for me is the Exchange integration.  I removed my previous IMAP account, and set up my Exchange account.  Biggest surprise for me: the iPhone will sync with Exchange over the air if you’re using a self-signed SSL certificate on your SBS / Exchange server.  It complains a bit that it can’t authenticate the certificate when you’re setting up the account, but you can acknowledge the warning and it will start synchronizing.  Naturally, if you select to synchronize your contacts and calendar, any contact & calendar data on the phone itself will be overwritten by data on your Exchange server.  For me this was no big deal as I was manually synchronizing this data anyway. 

I still have to play around a bit, especially with installing some of the new apps, but so far the Exchange integration is working just as I would have expected.  The contacts feature even handles multiple contact folders in your Exchange mailbox very nicely – even additional top-level contacts folders, and even allows you to search the GAL

Anyway, I’m off to go play on the dark side a little more . . .

SBS, SSL Certs and Verizon’s Treo 700w

So, there has been a decent amount of rumblings about the new Palm Treo 700w from Verizon Wireless (running Windows Mobile 5.0) – and it’s apparent inability to sync with SBS.


Sean has a good post outlining how Windows Mobile 5.0 has changed how it handles certificates.  The good news is that if you’re using self-signed certificates with your SBS, you can get your Treo 700w to sync wirelessly with your Exchange server.  As proof, I just did this myself – configured a new 700w for one of our internal users to sync with our SBS, and we’re using a self-signed certificate.


The trick is to install both your self-signed certificate ( <A href="file://\\\\<your_sbs\ClientApps\SBSCert ) AND your CA certificate (publishing.company.local –  check out  <A href="file://\\\CertEnroll”>\\<your_sbs>\CertEnroll ).  Copy these two .cer files to your device using ActiveSync.  Then on your device, use FileExplorer to browse to the folder where you copied the certs, and double-click to install each.  Voila!  You’re good to go . . .


Now, there has been some talk that WM5 doesn’t trust as many Certification Authorities (CAs) as regular ol’ Windows.  As a result, if you have purchased an SSL cert from a CA, there is a chance that CA may not be trusted by WM5.  In that case, you’re not going to be able to sync with your Exchange, since you won’t have access to the CA cert to manually install it on your WM5 device.  However, you could always convert to a self-signed cert and get it to work that way

Having issues with Outlook over the Internet?

Ok – so I have a new SBS Premium installation and all is going peachy, except that I can’t get Outlook over HTTP working.  It’s really annoying me, as I haven’t had any problem with any other SBS installation – Outlook over HTTP works great for all of them.  Mind you, OWA & RWW are working great – so I know 443 is getting to the external nic on the SBS ok.  I reran the CEICW and verified that ‘Outlook over the Internet’ was selected in the firewall configuration section.  Just to be safe, I compared the ISA settings to those on a working SBS – and everything matched – destination set, web publishing rule, etc.  I even checked the permissions on the /rpc directory under the default web site in IIS – everything is set just like it is supposed to be. 


So I started digging through my ISA logs, and in the web log I found where my connection attempts were hitting the server, and being dropped.  The log revealed a status code of 502, which according to Google indicated a ‘Bad Gateway’ error.   Huh?


So I posted to the Partner Newsgroups (you guys are aware of the MS Partner Newsgroups, right?  www.microsoft.com/partner )  Outlining the problem.  Woody Guo pointed me to URLScan, which was indeed installed on this machine as part of ISA FP1.  Specifically, he indicated the following edits were needed to the urlscan.ini file:


[RequestLimits]
; The entries in this section impose limits on the length
; of allowed parts of requests reaching the server.
MaxAllowedContentLength=2000000000
MaxUrl=16384
MaxQueryString=4096

In addition, you need to add the following verbs to the Allow Verbs:

RPC_IN_DATA
RPC_OUT_DATA

After editing the ini file, restart IIS Admin Service and Microsoft ISA Server Control services.


Needless to say, this did the trick and the client’s Outlook over HTTP is working like a charm!

UPDATED! SBSers – Make sure you’re not wrongly listed as an Open Relay!

** Updated on 11/12/04  5:19 P.M. CST (GMT -6)
The original post is further down – this is the update.


I’m sorry.  Where’s the duct tape?  Because I need to seal a few outbound ports and keep from hurting myself :^)


Here’s the skinny:  Almost all of our clients are running Trend Micro’s C/S/M for SMB for their Anti-Spam solution – however this one client is a non-profit and already had Symantec Corporate A/V, so they went with SpamCatcher that they were able to get from TechSoup.  Well, SpamCatcher works a little differently than Trend’s Anti-Spam.  SpamCatcher doesn’t integrate directly with Exchange – instead, when it is running on the Exchange server, it has to be configured to listen on port 25, then Exchange is reconfigured to listen on port 26.  As a result, SpamCatcher receives the emails on 25, then delivers them to Exchange on 26.  SO – since this is an SBS, SpamCatcher & Exchange are running on the same box, so Exchange is receiving its emails from it’s own IP.  Since Exchange on SBS is configured by default to allow itself to relay, this in effect opened this Exchange server up as an Open Relay – even though it was otherwise properly configured.


This also means that this IS NOT an issue with njabl.org – it was a uncommon configuration on this one server.  My bad :^(    Go ahead and whip me, beat me, and send me to my room without supper . . .


SO – the moral of the story is that if you’re running any sort of Anti-Spam / Anti-Virus / Anti-whatever that works similarly (actually receiving your email, then resending to Exchange on a different port), then you are most likely going to be an Open Relay. 


The other moral of the story is to remember to think THEN blog . . .   :^)


** End update – original post follows:


I received an email today from a client where they forwarded an NDR that they received.  The NDR indicated that their message had been blocked because they were blacklisted.  The specific blacklist indicated was njabl.org.  I went to the njabl.org site and performed a search on the client’s (static) IP, and sure enough – a result was returned.  In addition, the result included a message header from an automated open relay test njabl.org performed on the client’s server.  And there, right in front of my eyes was a message header that clearly showed that this client’s SBS had received the email and relayed it.  Remember – in a default configuration, Exchange on SBS 2003 is NOT an open relay.  That’s about when panic started to set in . . .


So I remote’d in to the client’s SBS and verified the relay settings for their Default SMTP Virtual Server – and everything was set how it should be – it was restricted to allow relaying only from the following list, which inluded the IPs of the SBS (internal, loopback & external).  The option ‘Allow all computers which successfully authenticate to relay, regardless the list above’ was unchecked, and the Users / Groups permissions was configured only to allow Authenticated Users to submit. 


Hmmm.   Next step was to take a look at my Message Tracking Center.  Sure enough, Exchange shows where it received the message and submitted it back to njabl.org.  What the #&%@ ?!?


I was getting ready to dig through my Exchange logs, when I took another look at the message header that njabl.org had displayed when I searched their database – and there it was, in plain sight.  The section of the header that showed where my SBS received their test message read:


Received: from rt.njabl.org ([192.168.16.2]) by  with Microsoft SMTPSVC(6.0.3790.0);


Ok, remember where I said above that there were three IPs in the Allow list in the Default SMTP Virtual Server relay settings – the internal IP, loopback IP & external IP?  This is a default configuration, and perfectly normal and secure (usually).  Take a look at that header line again – does the IP for rt.njabl.org look familiar?  Yep – that’s the default internal IP for an SBS – and by default, our Exchange is configured to allow relaying via that IP.  So this client’s SBS relayed njabl.org’s test message, not because it was an Open Relay, but because it just so happened that their server used to send the test message is publicly advertising a private IP that happens to be allowed.


I emailed njabl.org about this, and requested that they reconfigure their sending server to advertise a public IP, as they will be getting false positives from our SBS boxes in a default configuration.


So – my recommendation for the time being is to do a search on njabl.org to verify that your SBS servers are not wrongly listed as Open Relays, and to edit your Default SMTP Virtual Server relay settings by removing the IPs from the allow list.  Under normal conditions, this will not affect your performance  / functionality at all, but will protect you from being wrongly listed as an Open Relay by njabl.org if they don’t change their current procedures.

Dead Server Walking

Yesterday we got a call from a partner who sells / installs digital multi-function machines (those nice big copier / printer / scanner / fax units) who ran into a networking issue with a customer where he was trying to install a new unit and asked for assistance.  He claimed they had a Windows 2000 server and Win2k / XP workstations.  So I met him at this client, and proceeded to figure out why this one Win2k workstation wouldn’t see the network.  Well, I find that I can successfully ping the router, but I’m unable to browse the network.  I went back to the server to see if there was anything going on in the event logs.  Well, there was stuff going on – but nothing that would pertain to this issue.  So I grabbed the netbios name of the server while I was there, and went back to the problem PC to see if I had good name resolution.  I’m not sure why, but I opted to see if I could get to the server’s shares via  Run | \\<servername>  – well that worked.  Just as I was closing that window, I noticed a share on this Win2k Server that caught my eye:


mspclnt


As everyone knows – that’s the share for the ISA Firewall Client.  Now, looking at the shape of this LAN and only 6 PCs – I seriously doubted that they had splurged for ISA.  I went back to the server for a closer look – no SBS consoles or the like.  Then I opened the Add/Remove Programs snap-in and sure enough, there it was:  Microsoft Small Business Server.


Further investigation of the server & workstations revealed:


Two nics in the server – 192.168.1.1 & 192.168.1.2 – both plugged into the switch
All PCs configured with a static IP, using ISP’s DNS servers
No forwarders in DNS snap-in (hence ICW never ran)
Only 2 PCs actually joined to the domain – 4 others in workgroup
Total of 3 workgroups on the network – (Snap Server in it’s own?)
Snap Server not configured to use Windows domain authentication
All users accessing Snap Server via root credentials
Hodge-podge of A/V (whatever came on each PC – Norton here … McAfee there …)


And yes, it is a legal office  :^)      Luckily, we were able to step in just in time – someone had just about talked them into going with Merak Mail Server because   “Exchange is only for big corporations”   Wow . . . there’s a convincing argument . . .


Anyway – after a quick clean-up of some basic settings (like DNS), this looks like it is actually going to turn into a new SBS2k3 deployment in the next couple of weeks . . . I’ve gotta remember to buy Dan (the copier guy) a beer  :^)

SP1 straight from the horse’s mouth . . .

Ok, so Charlie (Anthe – Release Manager for the next version of SBS) isn’t a horse, but you get the idea . . . .


SBS SP1 will include:


Windows 2003 SP1
Exchange 2003 SP1
MSDE SP4
SQL Server SP4 (Premium)
ISA 2004 (Premium)
Windows Sharepoint Services SP1


And on the desktop side:

Windows XP SP2
ActiveSync 3.7.1

And yes Virginia – IT WILL BE AVAILABLE FOR ONLY SHIPPING & HANDLING!!!


Charlie also indicated that there will be a public beta for SP1, although they don’t know when it will be available or how it will be offered.  The target release date is to release at the same time as Windows 2003 SP1.

OWA 440 Authentication Timeout

As I mentioned in my earlier post today, I migrated my server here at home this weekend.  Well, once the new server was online, the only hiccup I discovered was that I couln’t access OWA.  I kept getting this bloody ‘440 Authentication Timeout’ page in IE.  And I would get it instantly, so there was no way it was actually timing out.  A quick google on this error returned a half dozen pages of threads, with no resolutions.  As a result, I figured I’d better blog this for future reference . . .


The root cause of this is the IUSR_<servername> and IWAM_<servername> accounts’ passwords being out of sync (between AD & IIS).  Here’s the steps necessary to fix this.  (And make sure to verify that neither of these accounts are locked out in AD!  I missed that the first time around and spent an extra hour and a half trying to figure out why it wasn’t working! :^)


1)  Open AD Users & Computers.  Expand the Users OU, right-click on the IUSR_<servername> account and select ‘Reset password’  Reset the password to anything you want (however, it can’t be blank).



2)  Open this User Account’s properties and verify that the account is not locked out  :^)  Also, make sure that ‘Password never expires’ and ‘User cannot change password’ are selected.


3)  Repeat steps 1 & 2 for the IWAM_<servername> account.  Close AD Users & Computers.



4)  Open Internet Information Services  (Start | Administrative Tools)


5)  Expand <servername> | Web Sites


6)  Right-click on ‘Default Web Site’ and select Properties.


7)  Go to the ‘Directory Security’ tab and click the Edit button under ‘Authentication & Access Control’


8)  Enter the new password for the IUSR_<servername> account and click OK.


9)  Enter the password again to confirm and click OK.


10) Click OK.


11)  Open a command prompt and enter  iisreset


12)  At the command prompt, enter the following commands:
        cd c:\inetpub\adminscripts
        adsutil SET w3svc/WAMUserPass <password>    (Where <password> = the password you entered for the IWAM_<servername> account in AD Users & Computers)
        c:\windows\system32\cscript.exe “c:\inetpub\adminscripts\synciwam.vbs” -v
        iisreset


Voila!  That should fix you right up . . .    :^)

So Exchange SP1 seems to have hosed your Companyweb?

Have no fear, young grasshopper . . .


So I’m applying Exch SP1 on the server here at the office (been running it at home for a little while).  So I finish the install and notice that I can’t access my Companyweb site . . . (which is a bit of a big deal for us – we’re becoming very dependent on Sharepoint . . . we might be able to survive a day without it – but that would be a maximum.


So I’m checking out the Event Viewer, and see the familiar 50070 error relating to Sharepoint.  Luckilly, I know that Susie has blogged this . . .   So I’m checking the fix, and realize that my MSSQL$SHAREPOINT service isn’t running, so I start it and it immediately stops.  So I tried it again (I mean really, did I think the service was playing with me and that by trying it again I’d effectively be showing it that I’m serious – I really want it to start?   But admit it – you’ve all done it too!  :^)   Needless to say – the second time wasn’t a charm.  I open Enterprise Manager to verify – and it cannot connect or start the Sharepoint instance either.  Well, maybe a reboot will help.  (Come on – it may be Windows 2003, but it’s still Windows!  ;^)   And it was a Service Pack installation, even though it didn’t tell me that a reboot was necessary.  So I reboot – and still no dice.


So, since I had ran with the first error I saw, I figured I might want to go check out a few of those other errors in the Event Viewer.  A few entries down, I found these two errors:


Event Type: Error
Event Source: MSSQL$SHAREPOINT
Event Category: (2)
Event ID: 17055
Date:  7/1/2004
Time:  5:28:24 PM
User:  N/A
Computer: DC
Description:
17120 :
SQL Server could not spawn FRunCM thread.


Event Type: Error
Event Source: MSSQL$SHAREPOINT
Event Category: (2)
Event ID: 17052
Date:  7/1/2004
Time:  5:28:24 PM
User:  N/A
Computer: DC
Description:
Error: 17826, Severity: 18, State: 1
Could not set up Net-Library ‘SSNETLIB’.


I googled the first, which didn’t help a whole lot.  However, when I googled the second, I at least got a decent number of threads, and the first few pointed to authentication.  Ok, that’s fine & dandy – but the MSSQL$SHAREPOINT service uses the Local System account by default.  I went into the MSSQL$SHAREPOINT service properties and verified that it was set to use the Local System account, which it was.  I decided that just for shits & giggles, I’d change the Log On parameters.  I switched from the Local System account to the Administrator account, and voila! the service finally started and I was able to access Companyweb.  I edited the service properties and switched it back to use the Local System account, stopped the service & restarted it successfully. 


I still have no idea what caused this – and I’m pretty sure that it was related to Exchange SP1 – I rebooted the server before applying the SP, I happened to open Companyweb right before I applied the SP (was thinking about looking something else up and opened IE instead of My Computer :^)  . . .   So Companyweb was working right before Exchange SP1 was installed, but broke after . . .