Windows 7 regional settings & Microsoft Access Errors

We’ve recently been swapping out our old XP machines for new Win7 machines and for the most part things have been pretty smooth (except you HP1020 printer – yes I’m looking at you). However, we did start to run into to some unexplained weirdness. We run an in-house order system built on an Access ADE/Access 2003 Runtime front end & a MSSQL backend. With the latest couple of new machines we started to see some errors, specifically when a user tried to use the MSCAL.OCX Datepicker. (it turns out we hadn’t run into the error before as the new machines were going to non-orderdesk people who didn’t use mscal) Now because users have Runtime & not a full version of Access, debugging these kinds of errors can be a challenge. I have lots of validation & error handling built in for user input issues but Runtime does not provide meaningful error messages on its own so when you run into a system related error, you just get a generic error message (yes there probably are ways to handle those kinds of errors too but not in -my- apps).

Things became even stranger as we found that User A had the error but when User B logged on to the same machine, they were able to use the app just fine. My initial thought was that it was a permissions problem for User A. We checked folder permissions for our app folder and everything seemed fine. We also checked to make sure both users had perms to the Access Program folder (where the OCX resides) and that checked out OK as well. I was tied up with some things so I had my assistant investigate a bit more. After some muttering & swearing (I may be projecting here), he returned to my office and said triumphantly, “Regional settings!”

For some reason User A had regional settings that were different than User B (who had the correct setup) Calendar control didn’t know what to do with the format it was being given so it threw an error.

Firstly, it’s awesome that “my guy” figured this one. In a very long series of assistants, he is the first one even remotely capable of the kind of thinking that finds these kinds of solutions. If you’ve ever uttered the words, “never mind, I’ll fix it myself”, you know what I’m talking about.

Secondly, I ran into this exact error when we made the switch from win200 to XPpro years ago but I didn’t make note of it. Now I have and I’ll be able to find a solution when we make the switch from win7 to win10 in 8 years time. :0

Modifying IIS 6 to allow subdomains using a wildcard ssl certificate to use port 443

History: By default, IIS websites cannot use the same SSL port (443) for a site using the same IP address. Websites with different IPs can all use port 443. This situation is typical of a standard SSL certificate which is issued to a single host header (ie: secure.website.com). Any other attempt to connect to a site via https through a different host header (ie: www.website.com) causes a certificate error (this is by design).

This becomes an issue when trying to install a wildcard SSL certificate. Wildcard certificates provide the ability to secure all subdomains on the root domain using a single certificate. (*.website.com) examples:

root domain – website.com

subdomains -admin.website.com, shop.website.com,etc

However, after you’ve installed a wildcard certificate and try to set up the subdomain to use SSL port 443, you will receive a Port In Use error. You will not be able to start the subdomain websites with the port set to 443. The IIS MMC (inetmgr.mmc) does not provide a method of resolving this so you must use the command line. (Start -> Run -> cmd)

You need to determine the site identifier of the subdomain you wish to modify. To determine <site identifier> Open IIS MMC, click on Web Sites and view the Identifier number next to the subdomain website. In the following script, replace <site identifier> with the number shown in the IIS MMC and change subdomain.website.com to the subdomain you wish to modify. Run the script with the modifications and you should now be able to browse to https://subdomain.website.com with no error.

cscript.exe c:\inetpub\adminscripts\adsutil.vbs set /w3svc/<site identifer>/SecureBindings ":443:subdomain.website.com"

if you have multiple subdomains, you could create a batch file to run the scripts.