Oh Joyous Day for IE7

From the IE Blog: we’ve also rebuilt the <select> element as a windowless control.

I noticed this first via Web Standards Project Buzz, where Lloydi rightly hopes they’ve fixed IE‘s myriad other SELECT problems.

As evidenced by my IE Bug Wiki participation, IE SELECT bugs demo, and IE bug solutions, this means a lot to me.

There’s a ton of other great news from the IE team there, including Page Zoom, tabs, integrated search, and Quick Tabs.  It sounds awesome — don’t miss it!

Another SBS SP1 hangup

I upgraded another client’s SBS 2003 machine to SP1 this past weekend.  It went remarkably smoothly, but we forgot to check their smartphones’ access to Exchange til today.  No connection, we checked the /OMA virtual directory, and got this error:

“A System error has occurred while processing your request. Please try again. If the problem persists, contact your administrator.”

Much “jiggling” (yknow, rerunning wizards, regenerating the web certificate, etc), and googling got me no answer.  I did see this error in the Application Log, though:

An unknown error occurred while processing the current request:
Message: The remote server returned an error: (403) Forbidden.
Source: Microsoft.Exchange.OMA.ExchangeDataProvider
Stack trace:
   at Microsoft.Exchange.OMA.ExchangeDataProvider.OmaWebRequest.GetRequestStream()
   at Microsoft.Exchange.OMA.ExchangeDataProvider.ExchangeServices.GetSpecialFolders()
   at Microsoft.Exchange.OMA.ExchangeDataProvider.ExchangeServices..ctor(UserInfo user)

Message: Exception has been thrown by the target of an invocation.
Source: mscorlib
Stack trace:
   at System.Reflection.RuntimeConstructorInfo.InternalInvoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean isBinderDefault)
   at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   at System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   at Microsoft.Exchange.OMA.UserInterface.Global.Session_Start(Object sender, EventArgs e)

Message: Exception of type Microsoft.Exchange.OMA.DataProviderInterface.ProviderException was thrown.
UserMessage: A System error has occurred while processing your request. Please try again. If the problem persists, contact your administrator.
Source: Microsoft.Exchange.OMA.UserInterface
Stack trace:
   at Microsoft.Exchange.OMA.UserInterface.Global.Session_Start(Object sender, EventArgs e)
   at System.Web.SessionState.SessionStateModule.RaiseOnStart(EventArgs e)
   at System.Web.SessionState.SessionStateModule.CompleteAcquireState()
   at System.Web.SessionState.SessionStateModule.BeginAcquireState(Object source, EventArgs e, AsyncCallback cb, Object extraData)
   at System.Web.AsyncEventExecutionStep.System.Web.HttpApplication+IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

What a mess.  But I recognized that “(403) Forbidden” as a web server error (although not on the actual OMA directory).  Combining that with info from similar OMA issues, I checked the /exchange-oma virtual directory’s settings, and aha! it was denying access to all IP addresses except and one we don’t use.  It was not making an exception for the primary local address.  So I added that and all’s now good.

So when you’re having OMA problems, try the usual stuff (including checking the OMA virtual directory), then also check settings on the exchange-oma virtual directory.

Lesson learned.

Update 2008-11-07:
Ha!  I was troubleshooting for a customer, and found my own post (top of the google to ya, 3 years later!)  It wasn’t the same issue, but it was similar enough to set me on
the right track.


Braindump: Dev Issues w/Outlook 2003 Custom Forms and Common Dialogs

I’ve been fighting with Outlook development again lately, custom form development in particular.  OL development is quirky, but there’s one circumstance where it’s downright bug-ridden:
Custom Outlook forms using Windows’ standard Common Dialog control.

The issues are numerous, but I’ll list them as I’ve found them:

“The control could not be created because it is not properly licensed”.

That link is to a thread in which Sue Mosher herself participates regarding her book’s suggestion to use the Common Dialog on Outlook forms.  A reader discovered licensing issues with this, and Sue confesses “I think we didn’t get it right, alas”

Kudos to her for that.  But there is a workaround: when I ran into the same issue several months ago, I found (can’t remember where right now, but I’ll update if I do) that, due to the Common Dialog’s (annoyingly dumb!) licensing, there’s a right way to use it and a wrong way.  Basically, if you programmatically create the control object, licensing restrictions kick in, and it will only work on machines with MS developer tools installed.  However, if you drag/drop the control onto the form, you can programmatically use it without a hitch. 

So, drag/drop the control and code to it, instead of using code like CreateObject("MSComDlg.CommonDialog"), and you should be good.

VBScript’s Native Error Handling is Broken

(Some?) Runtime VBScript Errors on Custom Outlook forms are suppressed.  Even with On Error Goto 0 explicitly set (which is the default in VBScript anyway), certain object-related errors are simply never raised. 

In particular, I was never actually getting the “The control could not be created because it is not properly licensed” error when I ran into it on users’ machines (who didn’t have MS dev tools installed).  Instead, that code was simply never running (as if I had On Error Resume Next set).  The only way I could track it down was by moving the code into a Windows Script, where native VBScript error handling does work:

…Not a great error message, but enough to google the answer.

Drag/Dropped Common Dialog Controls Become Invisible When Reopening a Custom Form

If you drag/drop a Common Dialog onto the form, it shows as a placeholder icon.  Save and the form template, reopen the template, and that placeholder icon is gone. 

I did determine that the Common Dialog is actually still there though.  I simply wrote some code which uses the control — when I reopen, that code still finds and uses the invisible control without issue.  Pretty confusing to anyone who doesn’t know/remember it’s there, though!

Custom Field Data + Common Dialogs Cause Security Warnings

Outlook 2002 SP3 and Outlook 2003 have a security feature which restricts ActiveX controls on one-off forms.  Basically, if you open a form template or one-off form which contains an ActiveX control, OL blocks the control and gives this error:

The solution to this problem is to not use one-off forms, and to instead publish them.

Unfortunately, this is not that issue, but it’s a somehow related OL bug.  What I found is that:
With items created from published custom form, which possess both custom fields and a Common Dialog control, if you save data in one of the custom fields, then you will get that error dialog on future openings of the item.

So another way of putting it:

  • I publish my custom form (with custom fields & Common Dialog). 
  • I can create a new item with it.  No problem.
  • I can even save standard field data in it.  No problem (reopening is flawless).
  • But as soon as I save data in a custom field and close, I get that dialog, and most of the form data is missing.

…I’ve found no documentation of this issue with this set of circumstances.  (Maybe it’s that rare, but I strongly suspect others have had it, which is why I’m airing it here).

It’s also a showstopper for me — I painstakingly worked around the myriad other Common Dialog issues, but I gotta open a file and have custom data on my form.  So now I’m looking into other controls.  Hopefully Sue was right in suggesting Word’s file dialog.  I don’t like the external dependency, but I’ve checked and it appears I can do that (this time).  OR, there’s also Windows’ native Shell.Application object’s BrowseForFolder method (which apparently has its own quirks).

For those considering embarking on the Common Dialog route, I’d recommend against it.  There are lots of alternatives.  I’ll post my results with those later.


  • The Word route didn’t pan out — 10 seconds to load the Word exe is way too slow for a file dialog.
  • I also tried Shell.Application’s BrowseForFolder method.  It’s a bit clunky, though, and way too quirky.
  • I think I’ve settled on a different common dialog: UserAccounts.CommonDialog, which is nearly identical to MSComDlg.CommonDialog.  Differences:
    • No licensing headaches
    • No OL security warnings
    • It requires Windows XP
    • “InitDir” property is renamed “InitialDir”

    …Not bad at all.  Still nice & snappy, with WinXP as the only requirement (certainly palatable for me).

Wishes for Windows Vista

Admittedly, I haven’t seen the beta yet, but I figured I’d get this out there in the hopes that someone who matters sees it…

Great idea for Windows: User Profile Templates and Machine Templates.  Essentially, they are just collections of registry settings, editable through a Tweak UI-like interface, and (most importantly) saveable as files.

User Profile Templates

These templates can be applied to existing profiles or the default user profile.  They would be editable and easily transferrable as files (Why? Because even though I’m a power user, I still like the Welcome screen).

Windows would include these Profile Templates out of the box (with example setting changes):

  • Beginner — pretty much what the default is now.
  • Intermediate — Windows Explorer switches over to details view, visible status bar.
  • Power User — All of Intermediate, plus: Quick Launch bar enabled.  Windows Explorer gets simple folder view disabled, filetype extensions visible, full path in address bar, encrypted/compressed files in color.  Windows Explorer & IE toolbars get compacted like so:

    Simple Folder View is disabled.

I don’t care if the default templates are editable, but if not, they should be copyable as the basis for other custom templates.  (If so, they’d need a “restore default settings” option).

Machine Templates

Same idea here, but for machine-wide (HKLM) settings.  Default templates would be something like:

  • Standalone Workstation — current defaults
  • Networked Workstation — RDP enabled, NetBIOS enabled

Here’s my reasoning behind this:

For Users: short of a new “GPOs for Workgroups” feature (which I’d love), power users need a way to manage workgrouped machines.  Even plain ol’ Power Users with Standalone Machines need an easy way to setup a machine which doesn’t require two hours of fixing stupid defaults.  Profile and Machine templates would greatly mitigate these issues for users.

For the Windows team, these templates would lessen the dev struggle between Features and Beginner simplicity.  Got a great but possibly-confusing feature?  No problem, just disable it for Beginners, and enable it for Power Users.

Also, miscellaneous Windows Explorer fixes/improvements I want:

  • Bring back the file filter which Windows 3.1’s File Manager had.  (Sure, disable it for the Beginner template).
  • Context Menus: speed them up by any means necessary.  (Click/wait is my biggest annoyance with a busy Windows box [like while copying files])
  • Context Menus: make them easier to edit (like IE, or ideally Office).  (I really want to move the “new folder” action from the “New” submenu to the main context menu!)
  • Make it possible to enable the Size column for Folders (without the current crashy 3rd-party addons)
  • Absorb BAxBEx’s FolderBox addon’s functionality.
  • Make the search windows honor the “Launch folder windows in a separate process” setting.  (Currently a hung/crashed search does the same to the shell Explorer despite that setting).
  • more as I think of it…

I realize some of these are advanced features

Stupid Outlook Peeves

That’s the actual title of a scribble note I made a long time ago. 

See, while I mostly love Outlook 2003, and it’s greatly improved since v2000, it still has a bunch of annoyances and artificial limitations that really get my goat.  To finish dumping the note:

  • Only 1 Exchange account setup is allowed per Windows (!) profile
  • POP accounts can only go to default delivery location’s inbox (unlike IMAP or Exchange accounts)
  • “After Sending” rules are missing several action options (which “When Arriving” rules do have).  In particular:
    • No “Move To Folder” option (Copy only)
    • No “Mark as Read” option
  • Tasks & Appointments which are outside the default delivery location are ignored (no reminders)
  • Can’t copy items from one PST to another (Move Items or Copy Folders only)
  • Folder views spontaneously and regularly get messed up
  • Subfolders can’t inherit parent folder’s view (an automatic option would be ideal, but manual would still be nice).

I noticed most of these while trying to maintain multiple accounts in Outlook, and keep their contents separate.  I used to use Outlook profiles, but switching is way too slow for that to be convenient.

Googling just now, I found a couple similar ruminations on the same subject: Limitations of Outlook (without Exchange) at inluminent.com, and
Outlook Limitations at outlookwise.com

More as it bugs me.

MSN Spaces tweaky thingy

Apparently MSN Spaces is now much more customizable, thanks to their new “Tweak UI PowerToy”.

Hey wait, though, Doesn’t Microsoft already already have a “Tweak UI Powertoy”?!  Ah, so they do!  (An indispensible Windows customization program, BTW).

Well, that’s ok, because MSN says to load it by typing “&powertoy=tweakomatic” on the end of the URL.  So perhaps we can just call it “Tweakomatic”…

Whoops, Microsoft already has a program called “Tweakomatic” too!  It writes scripts to programmatically accomplish what Tweak UI does.

…I can understand if the Spaces team really wants to be like the Scripting Guys (heck, I do!), but the name confusion has got to go!

SBS 2003 CAL suckiness

I have a new client who recently guessed their way through a SBS 2003 setup.  THEN they called us to fix it.  This has been quite the cleanup.  I gotta get me a Haz-mat suit.  Imagine and enjoy at my expense, some highlights:

  • Exchange mailboxes not configured for the POP3 Connector (so email was removed from the ISP’s mailbox, and dropped into Oblivion).
  • No backups, no (or patchy) virus/spyware protection (and plenty of spyware).
  • Moving from a XP Pro “server”, which fell apart when we tried to join it to the domain (due to loads of spyware).
  • XP Home machines trying to use the new server.
  • No extra CALs for the 12 user accounts.  Yes, that’s 12 users competing for the 5 licenses that come with SBS.  “Denied!”

And now (drumroll please)…

  • Amid extensive VPN, OWA, and OMA use, a vendor who supplied us with Device CALs instead of User CALs (and didn’t mention it until we’d already activated them!)
  • Crap.


    So I just saw this on Ajaxian Blog: “Ajax is rocket science”. “Ajax isn’t simple”. Enough already!

    It makes good points, but what puzzles me is: who is saying this?  I never found Ajax difficult (even when I first discovered it 5 years ago). 
    Are the complainers just web designers, who just build pretty-but-static HTML pages and don’t know coding (-vs- web developers, who build web apps)? 

    Well, as Scott would say:
    And then I got back to work.