Innovative Technology Weblog

I have had a love/hate relationship with the VMWare Server 2 beta for the last couple of months and today, I’m sorry to say we have parted ways. First up, my quarrel is not with VMWare products as a whole (I still love Workstation and ESX) but frankly with the poor interaction you get with VMWare in their own beta programs. It really is a far, far cry from the type of interaction and feedback you get in the Microsoft beta programs…

I would have been able to live with the lack of interaction if I weren’t having any major problems with the product. But as such things go, I ran into one showstopping problem… It turns out that on my hardware (which is a big, tricked out server that cost a small fortune and which I am not replacing) VMWare Server 2 had major issues correctly virtualizing Windows Server 2008 x64. Just that one OS. Everything else worked fine: Windows 2003 x86 & x64, even Windows 2008 x86 ran without a hitch. It has to be said that this is not a generic problem, since most others either don’t run into the problem (on a HP nx6325 laptop I also have no issues whatsoever), or they just don’t understand why things are breaking. But I’m certainly not the only one, judging from the replies and the 300+ views on the thread I posted in the VMWare Server 2 beta 2 community.

Now, I could manage without Windows 2008 x64 servers for a good while, since Exchange 2007 also runs on Windows 2003 (or if you’re really nuts like me, you can hack the x86 version on Windows 2008 into production ). But now that I’m participating in the Exchange ‘14’ TAP, I just have to have a Windows 2008 x64 machine. Either that or just don’t bother at all.

In my experience with Microsoft Technology Adoption Programs, Microsoft usually goes above and beyond to help their customers if they run into a blocking problem with the product, even if you are the only customer experiencing the problem. The experience with VMWare was pretty much the opposite, unfortunately. I have filed not one but two Support Requests and never have gotten more interaction than the support engineer asking me to run their support-info-gathering script (vm-support.vbs) and attaching the output to the Support Request. After that, either the support engineers go deaf or they just can’t help me anymore

So now I have grown tired of waiting for information that won’t come and I have decided to uninstall VMWare Server 2 and install VMWare Workstation 6 instead. I would’ve installed Hyper-V, but alas my 1st gen AMD Opterons don’t support the CPU Virtualization extensions needed for Hyper-V…

I’m actually quite sad to see VMWare Server 2 go, because I really liked the way you could manage VMWare Server 2 via the standard VMWare Virtual Infrastructure Client, even over the internet. I liked where VMWare Server 2 was going but it seems it was just to immature for my bleeding-edge needs…

Anyway, Workstation 6 has taken over now and my first Exchange ‘14’ server is (virtually) buzzing with a large grin

That’s a dozen more mailboxes to add to the running-Exchange-‘14’-in-production-count, DavidEsp!

The internet is a tricky world for doing business with – nothing new here. I would like to make a statement for WASHing everything that passes your DMZ environment. WASH is also the abbreviation for Web Application Security in a Holistic way. You like this one? In Dutch: een wasstraat.

No, really. Security is very important in the DMZ. The DMZ is typically the area of interest for washing application functionality and washing data transfer. Most of us already do this for email and internet traffic. And of course the firewall is delivering our basic security needs. But there are still many holes!

First hole: SSL websites.
Very few proxy servers are able to ”wash” SSL secure websites. And HTTPS is moving up. I suspect it will not take long for bad websites to abuse this hole too. I came by a solution called Clearswift Cleartunnel that extends the common ISA server with a SSL proxy. Hopefully Microsoft will put this feature into there ForeFront ISA 2008 version by default.

Second hole: XML messages
Open standards are promoted. XML is the major spin-off. So we protect HTTP and a lot of web protocols too, but XML is allowed blindly. What are we doing?!?! XML meta information is very, very useful for hacking purposes. We should mask our internal resources more carefully. Read this hacking example. So watch out for Web services applications that exists in the DMZ zone. These are commonly the applications that talk the XML protocol. As a solution I propose to accept only appliations that are designed by the WS-Security protocol principles. Otherwise look out for a XML firewall solution. Examples are: ForumSystems Xwall (also available as an ISA add-on), Cisco ACE XML Gateway, Vordel and Layer7.

Third hole: encrypted email messages
Email is the equivalent for SPAM (90-95% true). No wonder that email encryption is increasing popularity. Again, scanning there email messages is not an out of the box activity. Ideally you already have a mail security gateway supporting the common standards PGP (OpenPGP too), S/MIME and webmail. Some secure email gateways even support PDF mail. If you wish to be as flexible as possible you should support all common encryption technologies, I think. Multi functional solutions to consider are Exedra IQ suite, PGP Universal Gateway or the Utimaco Safeguard Mailgateway.

Fourth hole: FTP
Ancient technology. That is what FTP is. The HTTP protocol is much better to scale, load balance and secure. So my advice is to move to HTTP as fast as you can. Windows SharePoint Services is free to use on a Windows Server. So why not use it? 

Want more answers? Do you know of more holes to explore? Please post a reaction.

- Paul

I ran into a problem today (Feb 29th 2008) while installing a second Exchange 2007 server. The issue first became evident when noticed that I couldn’t move mailboxes from one MBX server to another. The error message I was getting everytime was “The Exchange server address list service is not running on SERVERX”…etc. I tried to find more info on the web and noticed that more people all around the world were experiencing similar issues, always with the Address List Service not running as the root problem. Me (and many others) were thinking that this could have something to do with the Exchange Rollup 1 patch for Exchange 2007 SP1, but even after removing it from all my Exchange servers the issue remained. Now finally, the root cause has been found: Exchange chokes on todays date!

It turns out an actual leap year bug has found its way into the Exchange 2007 product, causing problems all around the world. Changing the date has been confirmed both by Microsoft PSS and from people in the field to fix the problem. For everyone who can’t or won’t temporarily change the date of their entire system, you will have to wait until after midnight before you get everything back to normal (I sure don’t blame you, I have to wait as well). I do recommend rebooting your Exchange servers after midnight because I don’t think the Address List Service will come back online on its own.

A leap year bug….sheesh!

Read more about it here: http://forums.microsoft.com/TechNet/ShowPost.aspx?PageIndex=1&SiteID=17&PageID=1&PostID=2928121

I run Exchange 2007 SP1 on Windows Server 2008 RC1 and have run different beta’s of both products for some time now. In every case, I ran into the following problem: Outlook Anywhere (aka RPC over HTTP) would not work if the RPC-over-HTTP Proxy and the Exchange mailbox were on the same Windows 2008 server. Outlook would fail to connect to the server over the internet with some generic error message. When I was running the same configuration on a Windows 2003 server however, the problem did not occur. Also, if I put the RPC-over-HTTP Proxy on a seperate Windows 2003 server and the mailbox on a Exchange 2007 SP1 on Windows 2008 server, Outlook Anywhere worked just fine. I always thought it was a bug in either Exchange or Windows 2008, but I became convinced the problem was more serious when I still had problems with the official Exchange 2007 SP1 release on Windows 2008 RC1…

Meanwhile, I had already accepted the fact that I had to run the RPC-over-HTTP Proxy on a Windows 2003 machine for now, so that was how my environment was set up. However, when troubleshooting a different problem with Exchange, I stumbled upon the rootcause of the Outlook Anywhere problem! It turns out that the problem is in IPv6 and the way that Windows 2008 (and Vista btw) handles IPv6 as a preferred protocol over IPv4: When I did a “netstat -a -n” on my Windows 2008 machine, I noticed that Exchange was listening on the usual ports 6001, 6002 and 6004 on its IPv4 address, but only on ports 6001 and 6002 on its IPv6 address. The DSProxy service (port 6004) is NOT listening on the IPv6 stack!!! This now explains the behaviour that I was experiencing:

I just stumbled over a great tool from Information Patterns called Toucan File Finder. It allows you to search for files within your Groove workspaces. It is an external tool that searches within selected workspaces It is really a life saver for me. I really miss the search option within Groove and this tool just helps a lot.

Below is a screenshot of the tool.

You can search for anything that you want but you have to know what kind of file you are looking for. If you select a lot of workspaces to search in you will see that it takes some time to complete. So knowing what you are looking for is key.

I know you all want this and the best thing about it is that it is free!!! And because I’m Dutch this is the best thing . There is even no registration page WHOEPIE!!!!! And because you guys need to search a lot these days I will spare you a Google moment and just point you to the link. Click on this LINK to go to the download page.

See ya

Jeroen