Thursday, August 24, 2006

IIS Integrated Windows Authentication

Have you ever encounter a pop-up windows asking for username and password when you try to access an intranet site hosted on IIS with Integrated Windows Authentication even though you are login to your windows with domain account?

IE determines the URL address whether it is local or not by checking the URL if it is contain a dot (.) or not. If the URL contains a dot, it assumes the URL is not local, thus it won't pass the user domain credential to the server (what for?).

You can avoid this issue by putting the URL in your IE setting's Local Intranet Sites

Tuesday, August 22, 2006

MCSE - 1 more to goooooo

I've done 70-297 today. The score was 870!!
The nightmare is almost over :)

Monday, August 21, 2006

Change IIS Compression with C#

With Exchange SP2 on your front-end Exchange server, you might need to disable the dynamic and static compression with IIS to support GPRS for Windows Mobile Direct Push email.

You can either edit the Metabase.xml file and change the configuration directly like here or you can edit the configuration on the fly using the C#

Here is the code:

cscript C:\Inetpub\AdminScripts\adsutil.vbs set w3svc/1/root/Microsoft-Server-ActiveSync/DoDynamicCompression false

cscript C:\Inetpub\AdminScripts\adsutil.vbs set w3svc/1/root/Microsoft-Server-ActiveSync/DoStaticCompression false

Monday, August 07, 2006

Squid Reverse Proxy Redirect HTTP to HTTPS

To redirect HTTP traffic to HTTPS traffic when use Squid as the reverse proxy, use the following ACL in your squid.conf

acl httpPort myport 80
http_access deny httpPort
deny_info httpPort

Squid Proxy using parent with SSL

Squid can use cache_peer as the parent of the connection and uses SSL as the protocol. If the SSL certificate is self signed, you can use sslflags to bypass the verification:

cache_peer parent 443 0 no-query default ssl sslflags=DONT_VERIFY_PEER

Tuesday, August 01, 2006

Problems with Exchange server Activesync and Windows

Workaround - Problems with Exchange server Activesync and Windows
Mobile 5.


Windows Mobile 5.0 ActiveSync connection to Exchange 2003 via Orange or O2 GPRS network in the UK (may also be seen on other networks)

Error code 0x8503001A appears during sync and sync fails Exchange SP2 applied Sync works fine locally using Wifi or remotely via cradle/usb/internet link
Windows Mobile 2003 works fine in all cases Forms Based Authentication has been enabled at some point, with http compression.

After many hours of troubleshooting, I have found a workaround to the 0x8503001A sync problem that many people are experiencing.

The answer is that HTTP compression is enabled for Activesync in the IIS Metabase when SP2 is installed, and in conjunction with a (presumed) bug in Exchange where the IIS Metabase configuration is not
restored to previous settings after turning off FBA High compression,
causes the above problem.

These instructions will restore Activesync functionality for those
experiencing the issue.

First make a backup of the MetaBase:

Open IIS Manager Right click on server->AllTasks->Backup/Restore Configuration...
Click Create Backup
Give the backup a name (e.g. 'Backup before fix')
Click OK, Close

Then enable direct Metabase Edit

Open IIS Manager Right click on server and go to Properties
Check "Enable Direct Metabase Edit"
Click OK


Look for

IIsWebVirtualDir Location="/LM/W3SVC/1/ROOT/Microsoft-Server-ActiveSync"
and just below it, you will see:


Change both of these to FALSE (NB there are more of these throughout the METABASE.XML file, be sure only to change these two)

Save the Metabase.xml file back and restart IIS: Start->Run->IISRESET



Further information... In Metabase.xml, SP2 changes the above settings from FALSE to TRUE for ActiveSync. Presumably Compression is disabled overall until you enable FBA with Compression. The following line in
the METABASE.XML file acts as an overall ON/OFF switch for compression and also has the effect of providing a workaround (at the expense of losing http compression elsewhere, e.g. for OWA):

Look for the line HcNoCompressionForHttp10="FALSE"
Change FALSE to TRUE (the setting before enabling FBA with compression)

If you don't want OWA/FBA with any compression, I would safely assume you want to change the above line.

In fact, I would suggest that the Compression setting under Forms Based Authentication should be independently settable (not as a sub-option to FBA!)

There is a bug in all versions of Exchange which means once that
compression is enabled, disabling via the FBA screen doesn't reverse
the changes completely (as an SP2 install on a system that NEVER had FBA/compression enabled, will still function correctly).

The question for Microsoft is, how are compressed HTML packets getting corrupted by the mobile networks - obviously some NAT/Transparent Proxy in the way, but it's a weird one... And needs fixing (as well as the
"disabling compression doesn't actually do it" bug)!