So I have a client that is using Juniper's VPN to connect to their network.  Everything was working fine on Windows 7; however, when I tried connecting from Windows Server 2013, I kept getting a "The Network Connect session terminated.  Do you want to reconnect? (nc.windows.app.23712)" error.  Usually after about four or five times it would finally connect, but it was a PAIN to get things going.  Here is a little trick I discovered that will get it to connect every time: Open Control Panel => Network and Internet => Network Connections before trying to connect to the VPN--whenever I do this, it connects right away every time

I downloaded the FluorineFx code from http://www.fluorinefx.com and looked for sample code for authentication from Flash.  I finally found the code in the Samples\Flex\Remoting\MultipleClientAuthentication directory.  After authenticating, the Flex code called the "GetSecureData()" method and worked as expected, but the Flash example would always throw the "Requested access is not allowed" error message when calling the same secure service method.  I spent a couple of days searching the internet to find a solution and could find nothing so I decided to compile the source code and debug the solution to see if I could track down the problem.  It turns out that there is a bug in the code in the FluorineFx.Messaging.Endpoints.Filter.AuthenticationFilter class on line 106--the code calls the RestorePrincipal method but never assigns the returned principal to the principal variable and as a result, the principal is always null.

                        if (key != null)
                            // someone forgot to set the principal object in this code so it was always null
                            // FluorineContext.Current.RestorePrincipal(messageBroker.LoginCommand, key);
                            principal = FluorineContext.Current.RestorePrincipal(messageBroker.LoginCommand, key);

Hope this solution helps others save a little time in their searches.  Happy coding!

*****UPDATE***** 

Looks like this is only an issue if you use the setup.exe and use the source files from there.  If you download the source from SVN it has been fixed in the 4.0 project and the class is actually quite different.

I have a customer with a public-facing SharePoint website that is fed by a staging site.  This week we found an issue where some of the content on one of the production pages would not render; however, it was rendering fine in the staging environment.  We tried many things to fix the issue; however, nothing worked.  Ultimately, we decided to drop the site collection, re-create the site collection, and then re-publish the content.

Everything was going great until I ran the deployment job and received the following error:

"Unable to import the folder xxxx. There is already an object with the Id xxxx in the database from another site collection."

I thought maybe I hadn't selected the "select template later" option when re-creating the site collection so I dropped the site collection, re-created it, and tried publishing again; however, I received the same error.  After doing a few searches I found a post here that had the answer: my database had some orphaned objects that needed to be cleaned up.  Per Melick's blog post, I ran the following in SharePoint Powershell:

stsadm -o databaserepair -url <url name> -databasename <database name> 

Running the above will show if there are any orphaned objects.  In my case, there were many, so I ran the following command:

 stsadm -o databaserepair -url <url name> -databasename <database name> -deletecorruption

After that everything was cleaned up and I was able to publish the content to the site collection without having to drop the application as was suggested in several blog posts.

I was trying to upgrade from ESXi 3.5 to ESXi 4.1 and wanted to make sure I had all of the latest patches on ESXi 3.5 before the upgrade per suggestions I found on the internet.  This was the first time I had ever attempted to apply any patches, so I was surprised to see the patch attempt consitently fail at 60% with an error message of "Failed to INstall Update Firmware: Unable to Install".

After performing many searches, I discovered that there was a critical patch that needed to be applied before 1 June 2011 or you would no longer be able to patch ESXi 3.5. Well, this was the first I had heard of that and now it was 2 Jan 2012 and I thought I was stuck and wouldn't be able to upgrade. I finally found a post here that suggested rolling back the date on the ESXi host, and then running try installing the patch. I rolled back the date and the patching went smoothly. I then reset the date back to the current date and proceeded with the upgrade. The process I went through will be outlined in another post.

I am pleased to announce the launch of a new site: http://www.fellowes.com.  The launch is an upgrade of Fellowes' existing site from Commerce Server 2002 to Commerce Server 2009 hosted on Microsoft's SharePoint platform.  The site includes 7 different languages across 10 country-specific sites.  Some of the technologies used include:

• Commerce Server 2009 as the product catalog solution
• Microsoft SharePoint 2010 as the content management system
• Apache SOLR for search and faceted search
• jQuery, jQuery UI, and jQuery Tools for animation and user interaction
• mustache for styling of content returned from Apache SOLR
• nustache.net for styling of content returned from Commerce Server 2009

About Fellowes

Fellowes, Inc. offers an extensive range of products to equip the workspace, including paper shredders, binders, laminators, desktop accessories and record storage solutions.

Founded in 1917 by Harry Fellowes and headquartered in Itasca, Illinois, Fellowes, Inc. employs more than 1,800 people throughout the world and has operations in 15 countries.

I ran across an issue today that has bugged me for while, but I hadn't bothered to look for a solution until today.

My client has some custom master pages that are deployed via a feature as part of the package.  I've noticed for quite awhile that whenever we made changes to the master pages in Visual Studio, the changes didn't necessarily get deployed when we re-deployed the package so we would go into SharePoint Designer and make the changes manually.  I tried a few different things to resolve this, but nothing would work.  I finally found a post here that seemed to suggest something that might work--it essentially says to re-activate the feature to see the changes reflected.  DOH!  Sure enough, once I did that, I could see all of the changes.  Makes total sense--we are deploying the master page and page layouts as a feature, so they aren't updated until you re-activate the feature--wish I'd thought of that before .

So I was having an issue with a custom membership provider and SharePoint that I posted the problem and solution to here and here.

 Just thought I would post a note for myself so I could refer to it later.  Wasted a week on this one--hope no one else has to go through that.

I have a love/hate relationship with SharePoint, and for the last 24 hours I've been leaning on the hate part of the relationship.  

The Situation

I noticed the following messages in my logs on SharePoint:

Object Cache: The super user account utilized by the cache is not configured. This can increase the number of cache misses, which causes the page requests to consume unneccesary system resources. To configure the account use the following command ‘stsadm -o setproperty -propertyname portalsuperuseraccount -propertyvalue account -url webappurl’. The account should be any account that has Full Control access to the SharePoint databases but is not an application pool account. Additional Data: Current default super user account: SHAREPOINT\system

Object Cache: The super reader account utilized by the cache does not have sufficient permissions to SharePoint databases. To configure the account use the following command 'stsadm -o setproperty -propertyname portalsuperreaderaccount -propertyvalue account -url webappurl'. It should be configured to be an account that has Read access to the SharePoint databases. Additional Data: Current default super reader account: NT AUTHORITY\LOCAL SERVICE

So, I ran the commands and thought everything would be good to go--boy was I wrong. Suddenly I started getting "Access Denied" errors on every page that I went to. The logs weren't helpful in indicating what the issue was either. Finally I found a post here that definately applied to my situration--I was using claims-based authentication, but I had used [domain]\[username] when setting the super reader and super user accounts. I ran the script again with the correct accounts and...I still had the same problem. The only parts of the site I could get into was the site settings--I couldn't get into any other account. As a side note, I found that I also could not connect via SharePoint Designer--it would just result in a looping login.

The Solution

After hours of trying anything to get this to work, I decided to go to Central Administration and enable anonymous access and remove NTLM authentication. After changing these settings, I was finally able to get into the site! I then crossed my fingers, disabled anonymous access and added NTLM authentication again and voila--I could once again access the site.

Final Note

Just in case you don't see it in the blog post I referenced in this article, the super user and super reader accounts should be two separate domain accounts that are not used to log into the site. The super user account needs Full Control on the web application and the super reader account needs Full Read on the web application.

I've just launched a new site: causel.me

Causel was envisioned by my clients as a way to encourage outreach to various causes.  Their intent is to have a different cause every 100 days.  For every person that clicks the button to show their support, the sponsors will donate money to various causes.  None of the proceeds will go directly to Causel--the sponsors will donate directly to the specified non-profit organizations.  Their first cause is for the Japanese tsunami and earthquake victims.  I encourage you to visit the site and show your support.  You may support the cause once every 24 hours.

The site was programmed with jQuery Tools for the animations and Tempo for styling the RSS feeds.

Instructions for installing a multicore instance of SOLR plus Tomcat on Windows Server 2008 R2 were not clear anywhere.  I finally got everything to work by piecing together bits and pieces from various sites to get everything running.  The following are the steps I performed:

1. Downloaded and installed the 32-bit/64-bit Windows Service Installer for Tomcat
2. Installed Tomcat on the server (no special instructions here--just run the install and install wherever you wish)
3. Verified the installation of Tomcat by going to http://localhost:8080
4. Edit Tomcat's conf/server.xml and add URIEncoding="UTF-8" to the <Connector> element as shown here
5. Download SOLR from one of the mirrors found here (downloaded the apache-solr-1.4.1.zip package) and unzip the package
6. Create a directory where SOLR will be hosted from (in my case I used e:\inetpub\solr)
7. Copy the contents of the example\solr directory to your SOLR host directory (in my case e:\inetpub\solr)
8. Create directories under your SOLR host directory for each of the cores you wish to create (I created a dozen or so folders for each core I wanted to create in the e:\inetpub\solr directory.  The directories included en-US, en-CA, en-GB, etc.)
9. Copy the solr.xml file from the example\multicore directory and paste it into your SOLR host directory (e:\inetpub\solr for my example)
10. Edit the solr.xml file to include the information for each of the cores you created (if you created a folder under your host for a core named en-US, then add the following under the <cores> element in the solr.xml file: <core name="en-US" instanceDir="en-US" />)
11. Stop the Tomcat Service
12. Copy the *solr*.war file from the dist directory in the unzipped SOLR package to your Tomcat webapps folder
13. Rename the *solr*.war file to solr.war
14. In the notification area in the right-hand side of the Windows task bar, right-click on the Apache Tomcat 7 icon and select Configure
15. Click the Java tab and add the following to the Java Options text box: -Dsolr.solr.home=e:\inetpub\solr (change e:\inetpub\solr to wherever your SOLR is being hosted)
16. Click OK in the dialog and then start-up the Tomcat service
17. Open the conf\solrconfig.xml files under each of the cores you created and change the dataDir element to point to a specific directory.  If this step is not completed, all of your cores will be using the same data store for their data.
18. Stop and re-start the Tomcat Service
19. Test that your cores are running by running a query from the web browser http://localhost:8080/solr/en-US/select?q=*:* (replace "en-US" with whatever you've named one of your cores)

If I get a chance, I will update the instructions and add some illustrations to make it a bit easier to follow

****UPDATE****

I added steps 17 and 18 to my original post--if you skip this step, all of the cores will be using the same datastore and therefore overwrite each other.  Sorry I missed that the first time!