Hit a strange error that Google turned up blank on.

I had a password reset page that took some encrypted parameters and used SPClaimsUtility.AuthenticateFormsUser to log the user in and set the session token.

This code

Uri appliesTo = new Uri(Page.Request.Url.AbsoluteUri);


// Set the session token

SPClaimsUtility.AuthenticateFormsUser(appliesTo,user.UserName, txtNewPassword.Text);

would fail with a an invalid XML Error

System.Xml.XmlUtf8RawTextWriter.InvalidXmlChar(Int32 ch, Byte* pDst, Boolean entitize) +2670818
   System.Xml.XmlUtf8RawTextWriter.WriteElementTextBlock(Char* pSrc, Char* pSrcEnd) +5042301
   System.Xml.XmlUtf8RawTextWriter.WriteString(String text) +85
   System.Xml.XmlWellFormedWriter.WriteValue(String value) +1959831
   System.Xml.XmlWrappedWriter.WriteValue(String value) +17
   Microsoft.SharePoint.IdentityModel.SPTokenCache.GetBytesForSessionToken(String cookieContents) +123
   Microsoft.SharePoint.IdentityModel.SPTokenCache.WriteToken(SessionSecurityToken sessionToken) +304
   Microsoft.IdentityModel.Web.SessionAuthenticationModule.WriteSessionTokenToCookie(SessionSecurityToken sessionToken) +136
   Microsoft.SharePoint.IdentityModel.SPSessionAuthenticationModule.AuthenticateSessionSecurityToken(SessionSecurityToken sessionToken, Boolean writeCookie) +40
   Microsoft.SharePoint.IdentityModel.SPFederationAuthenticationModule.SetPrincipalAndWriteSessionToken(SecurityToken securityToken, SPSessionTokenWriteType writeOperationType) +485

The problem happens because the SPTokenCache is writing the tokenreference claim into an custom XML format.

The tokenreference contains, among other things, the AppliesTo Url.

XML has issues with characters outside a strict range including lower or higher Ascii characters.

The mistake i made was using Page.Request.Url.AbsoluteUri which includes the parameters passed to the page,  this included lower Ascii characters as part of the encrypted string (now this could be BASE64 encoded to avoid that).

The fix is to pass in only the current Web Url

 Uri appliesTo = new Uri(SPContext.Current.Web.Url);             

 // Set the session token

SPClaimsUtility.AuthenticateFormsUser(appliesTo,user.UserName, txtNewPassword.Text);

If you are getting a problem in SharePoint Diagnostics studio (part of the SharePoint Administration toolkit ) it can be useful to turn on tracing for the app.

Create a file called spdiag.exe.config in the same directory as spdiag.exe and put this in it

<configuration>
    <system.diagnostics>
        <trace autoflush="true" indentsize="4">
            <listeners>
                <add name="TextListener"
                    type="System.Diagnostics.TextWriterTraceListener"
                    initializeData="trace.log" />
            <remove name="Default" />
            </listeners>
        </trace>
    </system.diagnostics>
</configuration>

When you run SPDiag you will get a pretty detailed trace file generated.  For some reason this app tends to log exceptions rather than display them in the UI.

This helped me track down a blank report that was actually throwing an error behind the scenes.

System.Data.SqlClient.SqlException: Invalid object name 'TVF_RequestUsageAggregate_LogTime'.
   at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
   at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
   at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
   at System.Data.SqlClient.SqlDataReader.ConsumeMetaData()
   at System.Data.SqlClient.SqlDataReader.get_MetaData()
   at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
   at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)

I’ve just released a SharePoint 2010 solution for external SharePoint sites that need to comply with EU notification rules.

The control is activated on each Web Application and displays a message at the top of every page for each user until they click the confirm button. The confirm button stores a cookie which is detected on further page views and does not display if its detected.

This control allows active consent rather than implied consent.

Tested in SharePoint 2010 Foundation, 2010 Server, IE8/9, Chrome, Firefox.

Download from CodePlex: SharePoint 2010 Cookie Approval

So we have a development VM thats pretty fully loaded with software, Sharepoint 2010, Project Server 2010 and CRM 2011.

For some reason the First Azure project on this machine refused to deploy to the local development App Fabric. The deployment hung and never completed.

Nothing was posted in the event logs but there were items in the VS output screen about failing to write to the logs. Nice.

A search for those files found lots of Azure log folders in %localappdata%\dftmp

In DFAgentLogs and the DFAgent.log file I found this

[2011/10/13, 10:46:12.145,  INFO, 00011572] There is already a listener on IP endpoint 0.0.0.0:808.  Make sure that you are not trying to use this endpoint multiple times in your application and that there are no other applications listening on this endpoint.
[2011/10/13, 10:46:12.639,  INFO, 00011572]    at System.ServiceModel.Channels.SocketConnectionListener.Listen()
   at System.ServiceModel.Channels.BufferedConnectionListener.Listen()
   at System.ServiceModel.Channels.ExclusiveTcpTransportManager.OnOpen()
   at System.ServiceModel.Channels.TransportManager.Open..

Now we’re getting somewhere, the App Fabric Development Agent is trying to listen on port 808 and failing as another process has this port in use

A netstat –ano command shows the process id that is listening on that port

The Tasklist command tasklist /fi “PID eq 11400” shows that an exe call SMSVCHost.exe is listening on port 808

Thats the Net.TCP Port Sharing service. So the port sharing service is stopping a port being used. Marvellous.

I’m not sure which of the installed software set that service to automatically start.

After stopping the service and restarting the Development Fabric the deployment succeeded.

If you've installed Zune on a Server OS like Windows 2008 by running the zune-x64.msi directly as shown by Rob Mensching
http://robmensching.com/blog/posts/2009/9/12/How-to-install-Zune-software-on-Windows-2008-R2 you probably will get error 80040154 when checking for phone updates in Zune

The error means a COM component is not registered, its looking for a component with a CLSID of {31055FF4-9B90-42D6-9672-468E3ADE9583}

To fix this in the Zune Packages directory (where you ran the Zune install from) run zunewmdu-x64 (or zunewmdu-x86.msi) as Administrator and you should be able to update your Windows 7 Phone