Tips, Tricks, and Tales from the Techs

I just spent several hours working on a buggy OWA problem that presented itself as a “440 login timeout” issue.  If you’ve ever spent time trying to repair the 440 login timout issue, you’ll know that it is pretty straight forward.  You simply re-sync the IUSR_Machinename and IWAM_machine account passwords, run a couple scripts and your good to go.  But what if that doesn’t work?

I found a million articles that all said the same thing – iusr/iwam passwords out of sync.  That wasn’t it.  I started to poke around more, and noticed that there were several rights that were never assigned correctly.  I thought that was pretty odd, so matched up the rights with my own SBS 2003 server, and …..  it didn’t work!!!  Frustration is now setting in.  This actually was over several days of working on it a few hours each day.

So today, I’m poking around, digging inside of IIS and running Process Monitor from Sysinternals/Microsoft.  And darn if there it is in plain site – the user I’m trying to login with doesn’t have read rights to the folder.  I check, the DOMAIN\USERS group certainly has the proper rights.  I try again, same result.  I make a couple other changes, same result.  Finally it starts to sink in…is the Users group setup right?  The Users group is a default ‘Builtin’ group to Windows.  Its setup at the time of install and youre really not supposed to monkey with it.  So why would it be wrong?  Well, that in itself is a long story.

So I finally take a peek at the contents of the DOMAIN\Users group on the clients server as compared to my own server.  HOLY COW!!!!  The Users group was made up of about 6 standard users.  It was completely devoid of the default groups.  A healthy Users group should look something like this:

<!– /* Font Definitions */ @font-face {font-family:”Cambria Math”; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1610611985 1107304683 0 0 159 0;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4; mso-font-charset:0; mso-generic-font-family:swiss; mso-font-pitch:variable; mso-font-signature:-1610611985 1073750139 0 0 159 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:”"; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; font-family:”Arial”,”sans-serif”; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin;} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.Section1 {page:Section1;} –>

Their Users group didn’t have any of those three objects in there, but instead had 7 individual users inside.  So deleted the users that were present, and matched my own server and what do you know – OWA, OMA, and RWW all work like a charm now.

So the moral of the story is, don’t change the default Builtin groups unless you have a really good reason – and then don’t do it.  Its easy enough to build the groups that you need around the builtin groups and get the desired result.  Its not advisable to modify the default groups in any way.  They are there for a reason, and there are services, and applications that depend on them being setup in the proper way.  I took it for granted that the Users group would be the correct group from the gate.  Thats a mistake I won’t make again.  From now on, when debuggin any rights type problem, I’m going to be checking to make sure that the groups listed have the proper objects in them.  This is the result of non-admins doing admin work on a server.  So be sure to check that what you think is right – really is right.  Might save you some time – it would have saved me some time.

Sean Uncategorized

Recently I was dealing with an error with a windows mobile device that was trying to connect to an Exchange server on SBS 2003.  The error is pretty misleading with Support Code:0×85010014.  If you search the web you’ll find out about problems with Exchange activesync if you have forms based authentication and SSL required for your OWA page.  Well, running SBS this is the default configuration.  What I also found out, is the changes that are mentioned in Microsoft Knowledgebase 817379 are already done as part of a standard SBS installation.  So if you are working in SBS, you already have the changes that you would need to do to get this to work.  But I still have the error, so what do I do.  Well here is part of the actual error from the event log:

The remote server returned an error: (403) Forbidden.
Source: Microsoft.Exchange.OMA.ExchangeDataProvider

Searching the web for that string will turn up a nice blog by Mark Wilson regarding that specific error.  He mentions problems encountered if you performed a swing migration to new hardware.  Well on this particular server we had done exactly that.  But none of the fixes he mentions were needed as our HomeMTA settings were correct.  What could it be?  I was pulling my hair out.

One of the ways to test problems with SBS/OWA/Exchange is to try to access the directories and such through Internet Explorer, directly.  We were getting a 403 forbidden error.  Thats pretty important.  So, armed with my new knowledge from the above KB articles, I tried to log directly into the ‘exchange-oma’ virtual directory from the actual server itself.  I mean after all, that is what it does when you connect to OMA.  Well, what do you know.  I received a “You are not authorized to view this page”.  And deeper in the page you get to see the actual full error:

HTTP Error 403.6 – Forbidden: IP address of the client has been rejected.
Internet Information Services (IIS)

AH HA!!!!  Now I actually have a better idea of what is going on.  So the server has been denied by IP access to the virtual directory.  Now we’re getting somewhere.  So I open up the properties on the ‘exchange-oma’ virtual directory, and go into directory security, and in the middle of the page you have the option to ‘Grant or Deny access to this resource using IP addresses or Internet domain names’.  I entered that and low and behold, the IP address was wrong.  It was the address that we used on the server during migration.  We ended up putting the new server at the address of the old server when we were done.  So made that small adjustment and viola it was all up and running and the mobile phone was syncing.

So I took the opportunity to checkother virtual directories, and there are several that had the wrong info.  So I then re-ran the ‘connect to the internet’ wizard, which repaired the IP address on all the other virtual directories.  So the moral of the story is, if you change the IP address of your server, be sure to run the connect to internet wizard so that everything will be re-setup correctly, or you could be in a world of hurt later.

Sean Uncategorized