Joe Levi

Before I get to the "begging for help" part, let me quickly tell you who I am:

• I'm a Senior Web Developer for a relatively large company. I use Visual Studio 2008, connect to SQL Server 2005, and use IIS6 on Server 2003.

• I own two copies of Visa Ultimate Edition (one for my Tablet PC, one for my Media Center server).

• I've had Windows Mobile devices since I replaced my Newton MessagePad 130 with a Casio Palm Sized PC (and currently have an AT&T Tilt).

• I was an early adopter of the XBOX Original.

• I bought one of the first Zune's to market.

• I use BlogEngine.NET to run my personal blog, and SharePoint 3 for my family portal.

• In short, I'm a Microsoft supporter through and through.

...

More  at source: http://blog.joelevi.com/post/2008/04/Open-Letter-to-Microsoft-about-my-XBOX360-Failure.aspx

Register.com will charge you, what, $35/year to register a domain name with them. Other domain registrars like GoDaddy are less than $10.

Why everyone doing business with Register.com hasn't jumped ship is entirely beyond me. I jumped years ago.

Today I got an email from register to "get big business email for a small business price."

They say "D. Joseph.Levi@thebiglerfamily.com" beats "joe (at) joelevi.com"

What?! I'm Joe, my website is JoeLevi.com, but for some reason my full name (with a space in it? I didn't think that was legal in a properly formatted email address) at some other domain that I registered for a client beats my "me at my site" address? Really?

Wow.

First of all, I really don't like MSIE7's rendering mode, but it is better than that of MSIE6.

MSIE8 (Beta 1) is expected to ship in "standards mode" by default, in other words, "not compatible with MSIE7 pages mode." That could be a problem.

I use Yahoo!'s YUI CSS libraries to "zero out" all the discrepancies between browsers so I have a clean slate on which to build. Most of the time it works pretty well -- until MSIE8.

Even in "standards mode" MSIE8 renders my pages MUCH differently than MSIE7, Firefox 2/3, and Safari 3. Why? No idea yet. In the meantime, here's how to make your pages load the same way in MSIE8 as they did in MSIE7.

Add the following meta tag to your header:

<meta http-equiv="X-UA-Compatible" content="IE=7" />

Common Name	Compatibility Mode Value
"Quirks" Mode	IE=5
IE7 Mode	IE=7
IE8 Standards Mode	IE=8
Always Use Latest Mode	IE=edge

Of course that's not the "fix" but it will get you by until you can get to the root of the problem.

You can thank me later.

Recently we started getting the following error message on our ASP.NET 2.0 web application running on IIS6.

• Exception type:
  • CryptographicException
• Exception message:
  • Padding is invalid and cannot be removed.
• Stack trace:
  • at System.Security.Cryptography.RijndaelManagedTransform.DecryptData(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount, Byte[]& outputBuffer, Int32 outputOffset, PaddingMode paddingMode, Boolean fLast)
  • at System.Security.Cryptography.RijndaelManagedTransform.TransformFinalBlock(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount)
  • at System.Security.Cryptography.CryptoStream.FlushFinalBlock()
  • at System.Web.Configuration.MachineKeySection.EncryptOrDecryptData(Boolean fEncrypt, Byte[] buf, Byte[] modifier, Int32 start, Int32 length, Boolean useValidationSymAlgo)
  • at System.Web.UI.Page.DecryptString(String s)
  • [...]

The application provides forms authentication as the login mechanism for the end-user.

Apparently, whilst tuning the IIS settings for the application's App Pool (we forgot to set the max CPU use) we inadvertently turned on Web Garden and increased the "Max number of worker processes" from 1 (default) to 2.

Doing this created an unhandled problem, forms authentication uses the worker process to create an encrypted login chunk in the site's cookie. The encryption is specific to the worker process (even if it's on the same box). Therefore, if your user logs in using one worker process, then is shifted to another worker process, their login (as stored in the cookie) is invalid and they are prompted with to re-authenticate (which will be valid until they are shifted from that worker process to another).

There are ways to handle this, of course, so the user can hop between worker processes (or even entirely different servers) and still maintain a valid, authenticated session. But for us, we just set the worker processes back to 1 and restarted the app pool and all was well.

You can thank me later.