“The ‘fld’ start tag on line 1 does not match the end tag of ‘sFld’. Line 1 Position 3037”

This error appeared on a Customer’s Central Admin site recently, basically when trying to do anything useful such as view the Service Applications, change Diagnostic Logging levels, in fact trying to do anything useful with the farm.  It also manifested itself in PowerShell and if you viewed the Running Timer Jobs you noticed that they were ALL paused… NOT a good situation. 

After running through a number of recommended fixes or approaches on the forums, our team pretty much came to a standstill on this one.  Was it an error masking something else or was it actaully the correct error message?

So after a deal of looking around and finding nothing of use on the interweb, I contacted my fellow MVPs asking if anybody had had a similar message, and luckily one of the http://www.sharepointpt.org founders Rodrigo Pinto has experienced it in a test system using SharePoint 2007.  He said it really was the real error and referred to a corrupted entry in the SharePoint Config database.

So we dived into SQL Management Studio and looked at the [dbo].[Objects] table and with the help of Notepad++ and it’s extraordinary searching capabilities, we tracked down an entry relating to the User Profile Sync service which when put into XML Notepad displayed the exact same error as we were getting through the web UI and through PowerShell.

Here’s what I found :

<sFld type="Byte">196</sFld>
<sFld type="t">False</sFld>
<sFld type="Int32" name="profileStoreLanguage">1033</sFld>
<sFld type="String" name="profileStoreLanguagePacksApplied">[1033]</sFld>
<sFld type="Int32" name="profileStoreCollationId">25</sFld>
<sFld type="Int32" name="daysWorthOfEventsToKeep">7</sFld>
<sFld type="Int32" name="nextSynchronizationStage">2</sFld>
<fld type="Microsoft.Office.Server.Administration.UserProfileApplication+ILMInstallStage, Microsoft.Office.Server.UserProfiles, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" name="ilmInstallStage">C>0</sFld>
<sFld type="Byte">0</sFld>
<sFld type="Byte">0</sFld>

Now I don’t know about you, but I could see form the go get, that this was plainly the cause of the error. Position 3037 is highlighted in red. 

How on earth did this happen? Well we never found out, but the customer reported that a Virtual Host had failed the night the Timer Jobs stopped running, so I can only assume some weird write error to the Config database occurred as we later discovered that the system was part way through a User Profile Sync.

How did we fix it?  Well, we didn’t want to have to rebuild the farm, but as it stood we couldn’t actually de-provision the User Profile Service , as neither the UI or PowerShell were working enough to allow that, so that was looking likely, but we opted instead to carry out what is strictly an “Unsupported Action”, i.e updating a SharePoint database directly, but we felt in this case it was worth it for the sake of the customer, and ourselves. 

We had a good backup of the Config database form before the incident, so I could actually extract the entry before the incident occurred and indeed we examined the entry and it was perfectly formed XML unlike the above.  So after backing up all the essential databases again, shutdown the WWW service, Timer Service, Administration Service, Search Service, even FIM then I ran a simple SQL update statement to replace the above rubbish with the entry from the Config database backup and lo and behold, the farm sprung into life, timer jobs restarted, I could navigate around Central Admin and even view the User Profile Service management screen.  UPS Sync even had restarted up. 

Needless to say the customer was pleased as punch.

So sometimes you have do “Unsupported Actions” for the sake of the business.  Just don’t make a habit of them.

Cheers

Dave Mc

Advertisements

SharePoint 2013 Sandbox Solutions – Deprecated or Not?

Had this clarification today from Microsoft on the status of Sandbox Solutions:

“The only thing that is deprecated is sandboxed code. If you created a sandboxed solution in VisualStudio and set the “Include Assembly In Package” property to false, this is a declarative-only solution and that is not deprecated”

So basically provided there is no code in your sandbox solution you are good to go and that is not being removed from SharePoint 2013.

Hope that helps clear-up the rather confused messaging from MS about this!

Cheers

Dave Mc

 

Coaching is tough … but rewarding!

About a year ago I took my Level 1 Swimming Coaching qualification, in order to help out at Wyre Forest Swimming Club, as they were a bit short, and I fancied having a go, thinking it might also help my swimming. I’d seen a few people coach and it seemed to me like “how hard can it be?”.

Believe you me.  It can be hard.

The age group I’ve chosen to focus on at the moment is the 11-14 year olds. I love chatting and interacting with the children, and at that age, you hope they can begin to understand some of the more complex aspects of the sport.  But given a class of 20 odd kids, with varying levels of motivation, add to that a swimming training programme whereby you’re meant to get through 2500-3500m a session, add to that the swimmers wanting to go to the loo, adjust their goggles, forgot their hats, want to swim with their mates, forgotten their drinks, etc, etc it can turn out to be quite a frantic 90 to 120 mins of your life…

Some sessions just rock.  They just seem to click, the kids get on, they don’t fuss, they just do exactly what you ask and it’s oh so easy, you come away buzzing.

Other sessions, individuals are tired, motivation and effort is lacking and the programme doesn’t seem to flow, you come away disheartened and doubting your own ability.

Been through both types of session recently. Luckily I have several fantastic people I can turn to help for, coaches who have  forgotten more about coaching than I’m ever likely to learn, who I can only dream of emulating.

I love working with the kids, they are such fantastic characters each and everyone of them. They’re all volunteers, they all work extremely hard and it’s so fantastic to see them succeed.  When they hit a target time or win a medal, their faces just light up and it make all the hard graft worthwhile.

Swimming is such a hard, hard sport to compete in. It is one of the most gruelling training regimes out there, and much of it relies on the individuals self-discipline during training. Some children have that self-discipline naturally, others acquire it though training.  But the plain fact is , you cannot make everybody successful, you can only try to help people to be successful.  I think that’s a lesson I still need to learn myself …

Looking forward to the next session.  Hopefully I can say just one little thing to one of the kids which will make a positive difference to just one them and maybe help them get that County Time or that Gold Medal …

Cheers

Dave Mc

SharePoint 2013 “Sorry, this site hasn’t been shared with you”

This rather annoying message kept coming up on our on-premise (well on-Azure) SharePoint 2013 farm when we tried to create a new subsite of any kind.  After a fair amount of beating around and finding nothing around to indicate the cause, I eventually tried adding the current user to the Web Application User Policy in Central Administration and gave it Full Control.  That didn’t seem to work, still got the message.  I then tried the same again but also ticked the “Account operates as System” which did seem to work!  I then tried to add in a Security Group  with Full Control to the User Policy but this would not let me use the “Account operates as System” option.

So this workaround would appear to be OK for a test/dev/demo environment so we’ve opted for this at the moment, but seeing as you cannot have a Group operating as System it’s not really practical for production. I’ve seen other people say re-create the Web Application – well not really an option in this case.  So if anybody has the solution fit for production, please let me know!

Cheers

Dave Mc

SharePoint 2013 : Configuring an on-premise farm for Apps

At Ridgian we’ve stood-up an on-premise SharePoint 2013 Farm.  Well actually it’s running in Windows Azure under an extension to our own AD and one thing we wanted to test and run through is configuring the Farm for Apps.  Basically setting up our own App Store.

Now TechNet have a an article  http://technet.microsoft.com/en-us/library/fp161236.aspx which is a really good article and quite easy to follow.  There is one problem though.  If you are using SSL and do actually configure a separate DNS domain for your Apps, the article is incomplete.  There is one extremely important item missing and this item results in you always getting redirected to a 404 “Page Not Found” when you deploy and run your App.

Luckily Chris Whitehead, bless him, a Microsoft Premier Field Engineer has filled in the essential detail in his blog article http://blogs.technet.com/b/mspfe/archive/2013/01/31/configuring-sharepoint-on-premise-deployments-for-apps.aspx which took me quite a while to track down.

The missing item in the TechNet article is the “Routing Web Application”.  Basically when you have set up everything as per the TechNet article, I was left wondering how does SharePoint actually know where to redirect the request to when all the Apps have a dynamically created DNS name such as apps-12345678abcdef.yourappsdomain.co.uk .  Yes, it exists in DNS as a wildcard entry against your Apps server, but the server itself has no knowledge of this domain name and so refuses the request.  The trick is in this final step which Chris mentions but the TechNet article omits.  You create a new Web Application through SharePoint which has either:

  • A different IP address to the main SharePoint Domain or …
  • No Host Header if it shares the same IP address as the main SharePoint Domain.

This means that the server can now respond to any dynamically generated DNS name and SharePoint internals handles the fiddly routing bit. Now since we’ve run up our servers in Azure we cannot grant our Apps domain a separate IP address.  This results in another issue.  We end up with the Apps domain Web Application using the same certificate as the main SharePoint domain, so we get a certificate error coming up.  So on your production domain you need to have two IP addresses available in order to successfully implement an App Store using SSL without certificate errors.

I thought this stuff was meant to be getting easier!

In summary read both the TechNet and Chris Whitehead’s articles if you want to successfully run up a production App Store on-premise and make sure you have 2 IP addresses available. One for the SharePoint domain, one for the App domain.

Hope this helps

Cheers

Dave Mc

SharePoint 2010 : “The search service is not able to connect to the machine that hosts the administration component”

I came across this very annoying message when provisioning the SharePoint 2010 Search Service Application recently, and interestingly it occurred on two farms on the same network.  Both were brand new stand-ups a Test and a Production farm.  Both were two-server farms, a SharePoint and  a SQL Server database.  The message appears when you provision the Search Service Application and then navigate to the Search Service Administration page.  The full message is something like:

Crawl: The search service is not able to connect to the machine that hosts the administration component. 
Verify that the administration component c8519b74 status -<GUID> in search application Search Service 
Application is in a good state and try again."

There are numerous blogs relating to this  post but none of them helped me solved the situation.  So I decided to recreate one of the farms.  This is when I came across another problem initially when trying to create the farm in Powershell, I got the error:

“The given key was not present in the dictionary”

when I tried to create the Central Administration Database. When I used a different account the farm created perfectly OK.  I then tried to create some managed accounts.  Through the UI I got the same error again about the ‘the given key’, but with Powershell it was fine.  On Binging the problem I found the following forums thread:

http://social.technet.microsoft.com/Forums/en-US/sharepointadminprevious/thread/5279f8da-2924-461f-8c35-5b81a2329927

and the solution suggested which I have seen on other blogs is as follows:

Try this:

  1. Open up “Active Directory Users and Computer”
  2. Select “Advanced features” from the “View” menu
  3. Right-click the relevant account(s) and select “Properties”
  4. Select the “Securities” Tab
  5. Scroll down and select “Authenticated users” in the “Group or user names:” field
  6. Allow “Read” permissions in the “Permissions for Account Operators” field just below
  7. Hit Ok

Sure enough this solved the issue of “The given key was not present in the dictionary”.  I then proceeded to build the rest of the farm, but I still got the original problem of the Search Service being unable to find the administration component.

Eventually I tracked this issue down to there being an installation of IIS 7.5 Express edition having been installed for whatever reason on the SharePoint Server.  Along with this came the .NET 4.0 Client Profile and Extended Profile.  Now I’m unsure exactly which component it was caused the issue, but uninstalling all of then definitely solved the problem on both farms.

So in summary, make sure that IIS 7.5 Express, .NET 4.0 Client Profile and Extended Profile are NOT present on your SharePoint Server when you install.

Hope this helps

Cheers

Dave Mc

 

SharePoint 2013 PerformancePoint Database Dropdown Empty

When configuring PerformancePoint Services in SharePoint 2013, I struggled for a while with two problems when trying to create a Data Source for in the PerformancePoint Dashboard Designer:

  • No matter what server name I entered I didn’t get an error.
  • The database dropdown was always empty, irrespective of whatever server name was entered.

After many hours effort, recreating the PerformancePoint Service Application several times, I finally stumbled across this blog entry .  This seemed to tally exactly with what I was encountering, though I didn’t spot the exception in the ULS logs, but at this point I was happy to try anything.  The solution appeared to be to install the ADOMD.NET 10.0 on the SharePoint Server which is running PerformancePoint Services.  I did this but had to do the additional step of running an IISRESET in order to get the change to kick in properly and sure enough after this I managed to connect successfully to the Analysis Services cubes.

Hope this helps and thanks to James Love for this invaluable nugget …

Cheers

Dave Mc