On Saturday I booted into Windows 7 and read news as usual while eating breakfast. After that I rebooted into Windows 2008 R2 and wanted to work some on my test-project. After the boot load screen I got an bluescreen. Booted into Safe Mode, but again got an bluescreen. Tried to boot into Windows 7 but that bluescreened as well! WTF happened?!?

I would normally boot with a bootable utility CD to be able to fix problem or rescue files, but I thought this was an excellent opportunity to test a restore from my Windows Home Server backup.Luckily I had installed the WHS client on the Windows 7 machine and a full backup, including the VHD, was done Friday night. After 30 minutes downloading and burning the Restore CD and put network drivers on a USB stick – and then 1,5 hour restore time my machine was in perfect state.

Thank God for Windows Home Server!

When I tried to create a list I got the famous: 

Cannot complete this action.
Please try again.   at Microsoft.SharePoint.Library.SPRequestInternalClass.CreateListFromFormPost(String bstrUrl, String& pbstrGuid, String& pbstrNextUrl)
   at Microsoft.SharePoint.Library.SPRequest.CreateListFromFormPost(String bstrUrl, String& pbstrGuid, String& pbstrNextUrl)

In the Sharepoint logs I found this:

Failed to retrieve the list schema for feature [FEATURE GUID], list template [TEMPLATE]; expected to find it at: "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Features\[FEATURENAME]\[LIST]".    
Failed to find the list schema for FeatureId ‘[FEATURE GUID]‘, list template ID [TEMPLATE].  Cannot create list in web "[WEBURL]" at URL "(null)".    

This error is often caused by having more than one directory level in the feature folder. But in my case none of the suggestions Google gave me was valid.

I therefore tried to start with a fresh schema.xml but this time without modification. Deployed and added a list. No problem. I thereby modified the List attributes. Deploy. No problem. Added the content types. Again no problem. Added the fields. No problem! Added ViewFields. No problem!!! At this stage the schema.xml was practically identically to the one that caused the error – with one exception: The BaseView=”0” attribute of the List element was included in the working version. Hmmm, the documentation states that this attribute is optional. But as soon as I remove it, the error occurs.

Conclusion: The BaseView attribute is not optional. At least in this case…

The problem was that after writing the necessary 3 letters in the textbox I only got a looong list of ‘undefined’ entries. I tried to debug the webservice, but my code seemed never to run. I Googled and found others having the same problem, but their problem was caused by the fact that they returned only integers and not text.

I needed to find out what was happening in the background, so I started Fiddler and ran my solution, typed in a few characters and found this result from the server:

<span id="ctl00_PlaceHolderMain_LabelMessage">Could not create type 'Itera.IDM.Web._12.TEMPLATE.Layouts.IteraIDM.TitleService'.&nbsp;&nbsp; at System.Web.UI.SimpleWebHandlerParser.GetType(String typeName) <br>&nbsp;&nbsp;&nbsp;at System.Web.UI.SimpleWebHandlerParser.GetTypeToCache(Assembly builtAssembly) <br>&nbsp;&nbsp;&nbsp;at System.Web.Compilation.SimpleHandlerBuildProvider.GetGeneratedType(CompilerResults results) <br>&nbsp;&nbsp;&nbsp;at System.Web.Compilation.BuildProvider.CreateBuildResult(CompilerResults results) <br>&nbsp;&nbsp;&nbsp;at System.Web.Compilation.BuildProvider.GetBuildResult(CompilerResults results) <br>&nbsp;&nbsp;&nbsp;at System.Web.Compilation.BuildManager.CompileWebFile(VirtualPath virtualPath) <br>&nbsp;&nbsp;&nbsp;at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile) <br>&nbsp;&nbsp;&nbsp;at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile) <br>&nbsp;&nbsp;&nbsp;at System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory(VirtualPath virtualPath, HttpContext context, Boolean allowCrossApp, Boolean noAssert) <br>&nbsp;&nbsp;&nbsp;at System.Web.Compilation.BuildManager.GetCompiledType(VirtualPath virtualPath) <br>&nbsp;&nbsp;&nbsp;at System.Web.Compilation.BuildManager.GetCompiledType(String virtualPath) <br>&nbsp;&nbsp;&nbsp;at System.Web.Script.Services.WebServiceData.GetWebServiceData(HttpContext context, String virtualPath, Boolean failIfNoData, Boolean pageMethods, Boolean inlineScript) <br>&nbsp;&nbsp;&nbsp;at System.Web.Script.Services.RestHandler.CreateHandler(HttpContext context) <br>&nbsp;&nbsp;&nbsp;at System.Web.Script.Services.RestHandlerFactory.GetHandler(HttpContext context, String requestType, String url, String pathTranslated) <br>&nbsp;&nbsp;&nbsp;at System.Web.Script.Services.ScriptHandlerFactory.GetHandler(HttpContext context, String requestType, String url, String pathTranslated) <br>&nbsp;&nbsp;&nbsp;at System.Web.HttpApplication.MapHttpHandler(HttpContext context, String requestType, VirtualPath path, String pathTranslated, Boolean useAppConfig) <br>&nbsp;&nbsp;&nbsp;at System.Web.HttpApplication.MapHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() <br>&nbsp;&nbsp;&nbsp;at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean&amp; completedSynchronously)</span>

Aha! That namespace didn’t look right!

Since I created the source .aspx and .asmx files in the 12/TEMPLATE/Layouts/[SOLUTION]-folder, both files got an default namespace according this folder, like this: Itera.IDM._12.TEMPLATE.Layouts.IteraIDM. I had refactored it to Itera.IDM.Web and Itera.IDM.Ajax but forgot to update the .asmx file itself. Bummer!

Information got from this blog.

This was what I did:

• Make sure all sites use the same application pool acount in Central Administation > Operations > Service Accounts. I use Network Service for simplicity
• Make sure authentication providers use NTLM in Central Administration > Application Management > Authentication Providers
• Do a IISRESET and test that all sites works OK. If something doesn’t work now, it’s easy to go back if you remembered to make a note of previous settings for the first two steps
• Go to IIS Manager
• Create a new Application Pool:
• Call it something reasonable, like “Sharepoint Shared App Pool”
• Set Identity to the same identity as you used in the first step
• Configure Application Pool for each web site under Web Sites that you want to colsolidate
• Right click root of web site and select Properties
• Under Home Directory, change Application pool to the newly created application pool
• Expand the _layouts-folder under root and change the application pool for both images and inc
• Do a IISRESET and test that all sites works OK
• Delete the application pools you no longer use (when testet that everything works ok!)

After messing around I found the simplest solution was to alter the OOB core.js:

Changed:
cGCMinimumHeight=200;

to:
cGCMinimumHeight=600;

This offcourse makes the change global for all Datasheets and very exposed to future updates from Microsoft. So add it to your list of things to check after next upgrade…

Googling the problem gave me a couple of hints:

• Josh Gaffey’s Blog
• Tom Blog

… but none of them helped in my situation.

I tried to implement the new design step-by-step and noticed that the freeze-problem only occured when I changed the footer image. After a lot of trial and error I found what seemed to be the culprit of my problem. The footer image that worked was 322×19 pixels. The image that didn’t work 316×21 pixels. By resizing the footer image I found that as long as the height was 19 pixels I could change the width without any problem. Don’t ask why I tried this in the first place…

This correlates to Tom’s discovery which suggests that the GC-functions that resizes the grid is dependant on the scroll height. When the footer image got taller than 19 pixels – scroll height changes too.

Conclusion: Edit in Datasheet is VERY dependant on the layout. Hope Microsoft can fix this soon!

<?xml version=”1.0″ encoding=”UTF-8″ standalone=”yes”?>
<configuration>
  <configSections>
    <sectionGroup name=”SharePoint”>
      <section name=”SafeMode” type=”Microsoft.SharePoint.ApplicationRuntime.SafeModeConfigurationHandler, Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” />
    </sectionGroup>
  </configSections>

  <SharePoint>
    <SafeMode MaxControls=”200″ CallStack=”true” DirectFileDependencies=”10″ TotalFileDependencies=”50″ AllowPageLevelTrace=”false” />
  </SharePoint>

  <system.web>

    <customErrors mode=”Off” />

    <compilation batch=”false” debug=”true” />

  </system.net>
</configuration>

Googling wasn’t very helpful, so I had to investigate…

On my development machine in the file C:\Program Files (x86)\K2 blackpearl\Bin\configurationmanager.conf I found the solution. I just had to replace the default Host like this:

<plugins>
  <plugin text=”User Browser” description=”User Browser” makeAvailableOffline=”false” minVersionRequired=”4.0.0.0″ type=”SourceCode.Workflow.Plugins.UserBrowser.UserBrowserPlugin” assembly=”SourceCode.Workflow.Plugins, Version=4.0.0.0, Culture=neutral, PublicKeyToken=16a2c5aaaa1b130d” name=”User Browser”>
    <settings>
      <add key=”UserBrowserServer” value=”Integrated=True;IsPrimaryLogin=True;Authenticate=True;EncryptedPassword=False;Host=SERVERNAME;Port=5555″ />
    </settings>

Restart Visual Studio and everything should (hopefully) work.

Firstly – I assume you already know what Kerberos is and which problems it is intending to solve. This posting will not teach you this – but this might…

Even though I have tried to follow much of the available information out there, I was stuck on an issue involving an ASP.net frontend, WCF webservice and CRM backend. The reason was off course just ignorance and lack of better knowledge — as often is the case when dealing with something you don’t need to use often.

This is just a summary of my experience that might act as an checklist for others:

• Use separate domain accounts for each individual service / IIS application pool. This makes registering SPN’s cleaner.
• Use hostname’s (intranet.company.com, crm.company.com etc) for all IIS web applications and never refer to servername in calling applications.
• Register all hostname’s with A-records in DNS. Don’t use CNAME! And off course make sure the server is set up with static IP or DHCP record.
• Set up Kerberos Service Principle Names (SPN) correctly:
  • Register SPN for hostname’s only (HTTP/intranet.company.com) as SPN for web applications.
  • Don’t register HTTP/NETBIOS-name and HTTP/Fully-qualified-domain-name as many suggests.
  • Don’t delete HOST/SERVERNAME SPN’s registered on the computer account (domain\SERVERNAME$) or else you will get into trouble. I discovered it the hard way trying to clean up my SPN’s after doing a lot of testing. They can easily be re-created.
• Enable Kerberos logging: HKLM\Software\CurrentControlSet\System\Lsa\Kerberos\Paremeters\LogLevel = 1 (DWORD
• Enforce Kerberos to use TCP instead of UDP: HKLM\System\CurrentControlSet\Lsa\Kerberos\Parameters\MaxPacketSize = 1 (DWORD) to get rid of some Kerberos error messages
• Use DelegConfig to test Kerberos:
  • Make test-user member of  Local Admin group of server
  • Extract files to C:\Kerberos
  • Add virtual directory in IIS web application you need to test with Kerberos as Alias, C:\Kerberos as Path and and Read and Execute permission
  • On server in question, log in as test-user and go to HTTP://intranet.company.com/Kerberos) – pray to God for all green checkboxes
• When nothing of this helped – you’re on your own…