Workaround is to add a piece of javascript to the page in order to tell the spellchecker to ignore the user contact control.

 1. first add a <div id="'excludeContentFromSpellCheck'"> tag around the user contact control

 2. then add the following javascript 

      var a = document.getElementById('excludeContentFromSpellCheck');

      var b = a.getElementsByTagName('input');
       for (var i = 0; i < b.length; i++)

        {
             b[i].setAttribute("excludeFromSpellCheck", "true");   
        }

        var c= a.getElementsByTagName('textarea');
        for (var i = 0; i < c.length; i++)

        {
             c[i].setAttribute("excludeFromSpellCheck", "true");   
        }

So, looking for at a way to do this, I had to change a Local Security Policy, in order to allow them to be deleted:

* Open Local Security Policy MMC

* Goto Security Settings -> Local Policies -> Security Options

* Locate "User Account Control: Run all administrators in Admin Approval" and change the setting from Enabled to Disabled

* Reboot and now the assemblies can be deleted

IMPORTANT! Never ever do this on a production system, and always turn it back on afterwards.

If you have custom content types which inherit form the Page publishing content type (or any publishing content type), you will be able to upgrade your sites and create subsites - BUT you will not be able to create new site collections, or activate your custom content type feature on a standard publishing site, UNLESS you have the Inherits="TRUE" added to the ContentType element.

It seems not be a hard requirement for non-publishing content types.

Bottomline is that the Inherits="TRUE" attribute is new to SharePoint 2010, and when using inheritance you must make sure always to include this for new custom content types.

Check out the documentation and download the Visio diagrams:

• https://technet.microsoft.com/da-dk/library/ff829836(en-us).aspx
• https://go.microsoft.com/fwlink/?LinkId=196872

The safe place to look is of couse there: E-mail Integration for SharePoint Foundation 2010.

But being really Exchange-stupid, I needed some help and I found theses two guides below, which especially had nice screenshots of the Exchange 2010 pieces of the puzzle:

• https://sharepointgeorge.com/2010/configuring-incoming-email-sharepoint-2010/
• https://sharepointgeorge.com/2010/configuring-outgoing-email-sharepoint-2010/

Now, of course I had some problems anyway -- some because I was trying to do it too fast and missing some steps, but also a few weird things, I want to share:

* Most importantly, the timer service did not pick up the incoming eml messages in the SMTP drop folder - they were just sitting there. I had Incoming Email configured to "Automatic", which means it should pick up the drop folder location from the SMTP service. But for some reason, it couldn't contact the service. So, I ended up changing it to "Advanced" and entering the folder location of the drop folder, and then it worked.

* Also, I enabed the directory services in order to get the email contact created automatically. It created the contact fine, but it only added an external address for the contact - which meant it wasn't directly available in outlook contacts. So, when I added an internal SMTP address (same email address of course) then it worked. Again being at exchange 100-level, I didn't have a clue - but it worked and I got my things tested - which was want I wanted in the lab....

RTM software - check

Right product key - check.

Very wierd - so, I found this post of a similar problem, and sure thing it worked. Adding more rights for the app pool account did the trick.

I want to investivate this a bit more, so I'll update, if I find a solution without giving more access rights.

• Downloadable book: Planning guide for SharePoint Server 2010 Beta  (https://go.microsoft.com/fwlink/?LinkId=189513)
• Downloadable book: Deployment guide for SharePoint Server 2010 Beta (https://go.microsoft.com/fwlink/?LinkId=189303)
   

I guess the calculation is that the normal support has been extented until the 2nd Tuesday following the first CU after SP2 (and with all stars aligned....)

I thought that I would spend some time in a small series to post about findings, experiences and also share some of the tooling that help support build high quality sites.

Be Predictive -- So this is very most a process thing. Build the vision and scope based on requirements, and take the time to do A PROPER Logical Design and Information Architecture analysis.

Be interactive -- NEVER do waterfall projects on SharePoint. It is so much more valuable to iterate and have interaction on smaller releases. SharePoint customization is a great fit for this.

Produce high quality -- Do not underestimate the value of investing in proper release and build management in a SharePoint project. For any larger project it will be a lifesaver in the end. Releasing and building WCM artifacts in a larger team of developers and UX designers can be a challenging task, and form my experience, it cannot be done without incorporating and build test content.

Look out for the next posts where I'll dive into each of these...