I had installed VMWARE on one of my Windows 2003 (SP2) server to run an image file of Linux. In order to upgrade the VMWARE software to it’s latest version, I downloaded the new setup and ran it. It prompted me saying that the old version needs to be removed first and then the new one can be installed. Fortunately, it also told me that the Virtual Machines already configured will not be disturbed. That certainly brought a smile on my face, but not for long.

The uninstall process started but it seemed to keep crapping out. It would go so far (almost to the finish) and then just… sit there. Well, I almost sat there staring at the screen for a good 30-45 minutes, had 3-4 cups of coffee. Now this was torture.

I decided to kill the process and opened Task Manager. I could see 3 processes of msiexec.exe running along with the VMWARE-Server-Installer process. Surprised to see 3 process of msiexec.exe running, I picked a random one and killed it. To my surprise; the installtion proceeded and prompted me to choose if I wanted to keep the license key in the registry.

Hope this accidental discovery would help someone in the future.

I have an O2 XDA IIs which I wanted to sync over GPRS with my Exchange server in the office. Activesync used to work smoothly when I used to put the phone in the cradle but it failed to sync whenever I tried to sync it over GPRS or Wi-Fi connection.

I found that the problem was with communication over SSL (Secure Socket Layer) because the Exchange virtual directory in Microsoft Internet Information Server (IIS) is configured to accept only Secure Sockets Layer (SSL) connections on our server. Naturally this has been done to keep the security in place and to ensure that no passwords are sent out in clear text since Basic Authentication is enabled and Integrated Authentication is turned off.

Upon further research I found that Microsoft-Server-ActiveSync and Outlook Mobile Access virtual directories only try to connect with the Exchange virtual directory over TCP port 80 (HTTP) and does not make use of TCP port 443 (HTTPS).

I also tried adding Root Certificate to the PDA using the Microsoft solution as highlighted in their KB — but things do not work so easily for me — ANYTIME. It’s always hard work.

The best option was to take off SSL for OMA and ActiveSync. I exported the configuration of Exchange directory from IIS and imported the same under ActiveSyncPDA. After the import I removed SSL option from the virtual directory. The next step was to add a new parameter in the registry:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMasSyncParameters

and set it to point to the new virtual directory called ActivesyncPDA.

Restarted IIS and this time the sync from PDA worked over GPRS and Wi-Fi connections.

Yesterday I had a visit a client site for whom I support Exchange 2003 servers. They have an ISA 2000 setup and now want to migrate to ISA 2004/2006. The challenge was – how to do it. Even before that, they wanted to try out the publishing of Exchange Server’s Outlook Web Access over SSL from ISA 2004.

So, a new server was setup which had the ISA 2004 configured and which could talk to the current network so that the traffic from ISA can flow to Exchange server and vice-versa. The challenge was that their current FQDN did not point to the real IP which was set on the external interface of ISA.

In order to over come that situation where ISA would show a URL error, I set the client machine’s host header entry (which was outside the network) to point to the real IP of the new ISA server’s external interface. Next setup was to configure the new ISA to allow SSL Bridging between ISA and Exchange and configure it to use Forms Based Authentication (FBA).

After configuration of the above, I tried to access the FQDN from an external client and nothing happened. That was bad!!

ISA denied the request until I enabled “Require All Users to Authenticate” check box (which is not mandatory). This time I was happy to see the OWA screen on the client. But my worries did not end there. If I tried to login, OWA would not open the Inbox. Obviously the next step was to verify if ISA was able to authenticate the user credentials against Active Directory. Yes, checking the monitoring logs should that it could. So what was missing???

After some more hair pulling, analysis and some more hair pulling the loophole was found. ISA was not able to redirect the request to the Exchange Server for some reason. Added a host entry with the internal IP address of Exchange Server on the ISA Server and tried it once again.

Voila! We are there. Now the clients can enjoy their secure Outlook Web Access solution. Yes, the migration of ISA is still pending — but that’s a different story.

The other day I decided to check the Vista Firewall in detail since I had never actually gone through it after installing my beta version on the laptop. Considering the fact that security has been a prime concern recently for all small business and organizations, the Windows Vista Firewall surley has that “something more” in store. Here are some highlights that I would like to share:

• Different Interface: This time the firewall comes with more managible options compared to the Security Center that we have in Windows XP. There is a beginners interface which is accessible from the Control Panel while we have a more advanced interface for the geeks out there. This can be accessed by creating a custom MMC. It’s good in a way that the advanced controls are not left out in the open since this would prevent the beginners from disrupting the firewall rules while providing a way for advanced users to customize firewall settings more granularly and control outbound as well as inbound traffic. For network and system administrators, now configuring the firewall on clients can also be controlled via Group Policy settings.
• Secure by Default: The moment the firewall is installed, it is configured by default to block all incoming traffic while allowing all outbound. The Vista firewall also works in conjunctions with Vista’s new Windows Service Hardening feature. This means that if the firewall detects behavior that is prohibited by the Windows Service Hardening network rules, the firewall will block that behavior. The firewall also fully supports a pure IPv6 network environment.
• PING is Blocked: Digging deeper in to the advanced configuration, I noticed that all incoming ICMP requests were blocked. Well, that surley means that finding the host for hacking is going to be difficult now though it also means no more preliminary diagnostics unless the block is cleared.
• Inbound and Outbound Rules: Now that’s where I like to play. The advanced interface opens up a lot more features of the firewall where we can open up custom ports for specific programs. We can even make selection from some predefined configurations or run the rule creation wizard. The best part is that we can apply rules to services, ports or programs. Now that’s flexibility at work.
• AD Based Rules: This, I would say, is a blessing for network and system administrators. Now we can create rules which directly integrate with the Active Directory to block or allow connections based on Active Directory User, Computer, or Group Accounts. The flip side — the connection should be secured by IPSec with Kerberos v5.
• Multiple Policies: Using the MMC snap-in for advanced configuration we can set up multiple firewall profiles so that we can have a different firewall configuration for different situations. I created three firewall profiles on my laptop: one for connecting to my domain in office, one for connecting from my Home Wi-Fi network, and one for connecting from a public network (specially while waiting at the airports furing delayed flight schedules).

There are lot of other features relating to IPSec, Custom Authentication Rules, Security Wizard for creating Security Rules, etc. but I think they would not appeal much to the general public so I’m keeping them off the list.

The bottom line is that the Vista Firewall is no longer Basic.