The fix is very straightforward: Allow Read permissions in the Windows registry to the identity running the application. In our case, we’re dealing with a web application so we had to add the application pool identity (NETWORK SERVICE) with Read permissions to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Security key. This allowed the proper access and everything fell into place.

References

• System.Security.SecurityException when writing to Event Log: http://stackoverflow.com/questions/1274018/system-security-securityexception-when-writing-to-event-log

The following articles include great information to configure the URL Rewrite module for redirecting HTTP to HTTPS. You have both GUI and configuration file options to set this up depending on your preference. This article probably has the best synopsis for both approaches and make sure you take a look at 10 great URL Rewriting tips for other great uses of the URL Rewrite module.

References

• Automatically Redirect HTTP requests to HTTPS on IIS 7 using URL Rewrite 2.0: http://www.jppinto.com/2010/03/automatically-redirect-http-requests-to-https-on-iis7-using-url-rewrite-2-0/
• 10 URL Rewriting Tips and Tricks: http://ruslany.net/2009/04/10-url-rewriting-tips-and-tricks/
• IIS URL Rewrite 2.0:

  http://www.iis.net/download/URLRewrite

• IIS7 Redirect HTTP to HTTPS: http://www.sslshopper.com/iis7-redirect-http-to-https.html
• Redirect HTTP to HTTPS with IIS 7: http://www.iis-aid.com/articles/how_to_guides/redirect_http_to_https_iis_7

The articles below should help you create efficient LDAP queries. One key is to make sure attributes you search on often are indexed in Active Directory. You can also save a lot of cycles by sorting on the client and searching by objectCategory instead of objectClass.

• Creating Efficient Filters and Other Tips: http://msdn.microsoft.com/en-us/library/windows/desktop/ms808539.aspx#efficientadapps_topic01e
• Searching for Users: http://www.activedir.org/Articles/tabid/54/articleType/ArticleView/articleId/28/LDAP-tips-1-Searching-for-Users.aspx

Nested Filter Tips

Avoid deeply nested complex filters when you can. When you must use complex filters, place the most specific filters first to narrow the list of candidate entries the directory must check. For best results, use not, !, only with and, &, for example (&(cn=Barbara)(!(sn=Jensen))). When you use not with or in a filter, the directory must construct a candidate list of everything except what your filter specifies.

-From http://blogs.oracle.com/marginNotes/entry/ldap_client_application_development

Once you have the certificate from the CA, you still need to take a couple of steps to finish the process. In our case, we used the OpenSSL tool to create our CSR and private key on Server 2008 and then sent the CSR to our CA. This process went smoothly and we didn’t hit a snag until we needed to combine the certificate with the private key to create a PKCS#12 file—with a PFX extension—we can use to sign installers and .NET assemblies.

We used the PVK Digital Certificate Files Importer utility from Microsoft—pvkimprt.exe—to combine the certificate with the private key and produce our PFX file. However, when running the command to combine the files as described here, we ran into the following error.

Error: 000004c0, The format of the specified password is invalid.

This head scratcher caused some consternation since I hadn’t even been prompted for a password. After much searching and cursing, I found the following fantastic articlefrom a fella that ran into the exact same issue a couple of years ago. The culprit that causes the pvkimprt utility to fail is the private key created by OpenSSL does not work with pvkimprt. You need to use the PVK Utility to convert the OpenSSL private key to a format that works with pvkimprt.exe. Once you download the PVK Utility, just run PVK from a command line like follows to generate a compatible private key file for pvkimprt.

pvk.exe -in privateKey.key -out privateKey.pvk -strong -topvk

Once you have the converted pvk file, you can run the pvkimprt utility again and it should fire up the Export Private Key wizard and allow you to complete the creation of your .pfx file.

References

• Killer article that puts it all together: http://blog.powerwf.com/post/347822685/realworld-code-signing-for-dummies
• Another good article describing the problem: http://www.xxeo.com/archives/2004/05/06/whipped-cream-microsoft-authenticode-pvkmprtexeerror-000004c0-and-other-delights.html
• PVK Utility download: http://www.drh-consultancy.demon.co.uk/pvk.html
• Install a code signing certificate: http://support.godaddy.com/help/article/5087
• Generate a CSR from OpenSSL: http://support.godaddy.com/help/7282/generating-a-certificate-signing-request-for-code-signing-certificates
• Request a code signing certificate: http://support.godaddy.com/help/4777?locale=en

Exception occurred in System.Web: Invalid viewstate

This obviously has something to do with the load balancing switching between servers but what’s the best way to handle it? The error itself is caused because ASP.NET thankfully performs a check—called a machine authentication check (MAC)—when ViewState data is posted to a server. This helps protect against scenarios where a malicious client might tamper with ViewState data and try to post harmful data to the server.

The MAC works great except when you have more than one server…then it causes problems because the private machine keys are different among the servers in the farm. You have two main approaches to address this.

1. Turn off the MAC check by setting enableViewStateMac=”false” in your Web.config or pages for each web server. I don’t recommend this approach unless you have an internal non-public facing scenario.
2. Use the same machineKey attribute value in the Web.config for all servers in the farm. Check out this article for a great set of instructions to set the machineKey to the proper value. I highly recommend this approach for public-facing web farms.

References

Check out the other great resources here for more information about load balancing an ASP.NET web application that uses ViewState.

• Load Balancing and ASP.NET
• ASP.NET and Load balancing
• ASP.NET load balancing and ASP.NET state server (aspnet_state)
• machineKey Element (ASP.NET Settings Schema)

To download the vSphere Client, point a browser to the server name or IP address of one of your vSphere hosts and you will get a page that allows you to download the vSphere Client. You will probably need to use SSL (https://) to connect.

https://vSphere_Host_Name or IP Address

My page looks like the one below for the 4.1 client.

vSphere 4.1 Client Download Page

I messed with this issue for a while and found a great post that helped break open the case. We use InstallShield 2009 (yes, it’s time to upgrade to InstallShield 2012 or 2013…that will happen soon) for our installer builds. The article comments mention that “DotNetCoCreateObject does not work if your dll has been built with .Net Framework 4.0 with Installshield 2010 and below.” Aha! That’s exactly what we were doing. So how do we address the issue other than upgrading to a version of InstallShield after 2010?

We worked around the DotNetCoCreateObject() method issue in .NET 4.0 by adding a .NET 2.0 project to our solution and isolating our installer actions in that project. You also need to ensure that the assembly’s ComVisible attribute is set to true either through the AssemblyInfo.cs properties or in the project property sheet for the advanced assembly options. Then you can build your solution in Visual Studio, add the new .NET 2.0 assembly to your InstallShield project and call the .NET 2.0 assembly with the  DotNetCoCreateObject() method. This should avoid the -2147219705 error and execute your custom action properly.

Setting up the email account with Office 365 was a bit vexing and I want to share my experience to help streamline the process. I used this article on Microsoft’s Office 365 support site to help get the proper settings in place and the most important pieces for me included the following.

• Use your Microsoft Office 365 email address and domain name, not your custom vanity domain. In my case, my email domain is webactivedirectory.com but I needed to use my domain of webad.onmicrosoft.com.
• For the DomainUsername setting, use your full user name and mail domain. For example, if your email address is richcranium@webad.onmicrosoft.com, type webad.onmicrosoft.comrichcranium@webad.onmicrosoft.com.
• Get your Exchange Server name from the Office 365 Outlook Web Access (OWA) Help > About page. You can try the External POP Settings > Server name value first if you want. However, if you are on a podxxxxx.outlook.com server you will need to use either m.outlook.com or, in my case, the value in the the Host name line on the About page, which is a much more complicated server name like bl2prd0654.outlook.com.

Once I authenticated to the proper server with the proper credentials, the Ice Cream Sandwich OS automatically set up syncing of mail, contacts and calendar. For the first time since we switched to Office 365 in May 2011 I can actually get my contacts and calendar synced to my mobile device. Woohoo! Bye bye RIM! Good riddance!

The Procedure entry point FLSAlloc could not be located in the dynamic link library KERNEL32.dll.

Net 4.5 Developer Preview Installation Error on Windows XP

Whoa there, Nelly! What’s going on? Well, simply put, .NET 4.5 will not run on Windows XP, and requires at least Windows 7 or Windows Server 2008. I guess this day has been coming for several years and it’s been time for me to upgrade my development machine for some time. Maybe now I have the impetus to do it. Welcome to the twenty-teens, eh!

A subtle issue with the PrincipalContext constructor caused the COM Unknown Error and watch out for this when working with any of the System.DirectoryServices.AccountManagement classes. Merely passing blank values—empty strings—to the constructor for default parameters does not behave nicely and results in the COM Unknown Error. You must explicitly pass null for these values and then you will get the expected default behavior. You might use a pattern to check for empty string parameters in your wrapper class and set these values to null before constructing a PrincipalContext.

I suspect under the covers that the library authors include empty strings (String.Empty) as valid values and go ahead and pass these values to the underlying directory store. Of course, this causes an issue with most directories so just make sure to pass null.