Shared Service Provider Access Denied

As I have had plenty of time playing with MOSS installs/upgrades over the last week (in between jobs), I discovered an interesting behaviour with Shared Service providers. I tried to simulate a proper production install, so I installed MOSS and configured the farm with a test administrator account (e.g. testadmin). During the upgrade process (database migration of the _PROF, _SERV and _SITE db) I logged on as a different administrator (not a domain admin, but a local admin on the box). Well the upgrade went through without a problem and I was able to restore the SSP. I then added myself to have full control over the dev intranet site and the SSP site (using Policy for Web Application). I then navigated to the SSP site and configured the search. Then I went to update the profile information and it was there that I got the old Access Denied, you must sign in as someone else. After scratching my head for a while, I discovered the 'Personalization services permissions' hyperlink in the SSP site. So I logged back in as testadmin (who at this time was the only user who could actually get to the profile settings page), invoked this function and added a new group to the list, giving them 'Create personal site', 'Use personal features', 'Manage user profiles', 'Manage audiences', 'Manage permissions' and 'Manage usage analytics' rights, and low and behold I was able to edit profile settings with my normal local administrator account.

My last week at SDM

Well it was a tough decision, but I have decided to leave SDM and start my own business (MS-Advantage Pty Ltd). I start a 9 month contract with DiData on Monday the 30th of April.

It will be sad to go, but I am looking forward to the challenges ahead. SDM is a great company to work for with some very talented people.

Update on SharePoint ASPMenu control

It ended up being caused by a custom developed breadbrumb control that was requiring extra credentials in order to query the parent site title. We ended up having to remove the control.

SharePoint ASPMenu control is prompting for user credentials if it finds draft documents on the public site

I am working on an MOSS internet project at the moment, and today I came across a strange behaviour in development where users get prompted for their credentials.

Background
Basically I setup a staging environment and did a full deployment through an ISA firewall to a destination server. I then setup anon security on the destination site. After making some changes to pages in development, I then ran a deployment to copy across changed files since the last deployment. One of the things I noticed (and I wasn't aware of this) was that during a content deployment, it is not only the published files that get deployed, but also Draft pages. It doesn't seem to matter whether it is a full deployment or only the deployment of changes - draft content still gets sent across (which is bad).

Now I have a couple of Master pages, each of which contains 3 content placeholder ids (PlaceHolderLeftNavBar, PlaceHolderMain, PlaceHolderAdSpace). The page layout used only overwrites the PlaceHolderMain and PlaceHolderAdSpace regions (i.e. no reference to PlaceHolderLeftNavBar at all). In this case, my main master page outputs the ASPMenu control in the PlaceHolderLeftNavBar space. My other master page contains the 3 content placeholders, but does not put anything into the PlaceHolderLeftNavBar area (and as the page layout doesn't reference this id also, nothing gets rendered in the left nav area).

The Experienced Problem
On the destination server, when the master page with the ASPMenu left nav gets used, if there is any draft pages that it finds, it prompts for credentials, instead of just hiding them. If I switch master pages so that the ASPMenu is no longer rendered on the page, the user does not get prompted.

If anyone knows why this is and knows how to fix it, please post a comment.

Microsoft ForeFront may cause WCM deployment to fail

Today at a client site I noticed that content deployment just stopped working from my staging environment to the live site. Basically the job said that it failed, but gave no errors or warnings at the staging environment end. So I started to investigate what was going on within the destination server. The event log had the following error:

Failed import operation for Content Deployment job 'Remote import job for job with sourceID = f483830c-116d-4fd1-9d68-5dc6df9bd2cf'. Exception was: 'Microsoft.SharePoint.SPException: Exception from HRESULT: 0x81070000 ---> System.Runtime.InteropServices.COMException (0x81070000): Exception from HRESULT: 0x81070000
at Microsoft.SharePoint.Library.SPRequestInternalClass.AddOrUpdateItem(String bstrUrl, String bstrListName, Boolean bAdd, Boolean bSystemUpdate, Boolean bPreserveItemVersion, Boolean bUpdateNoVersion, Int32& plID, String& pbstrGuid, Guid pbstrNewDocId, Boolean bHasNewDocId, String bstrVersion, Object& pvarAttachmentNames, Object& pvarAttachmentContents, Object& pvarProperties, Boolean bCheckOut, Boolean bCheckin, Boolean bMigration, Boolean bPublish)
at Microsoft.SharePoint.Library.SPRequest.AddOrUpdateItem(String bstrUrl, String bstrListName, Boolean bAdd, Boolean bSystemUpdate, Boolean bPreserveItemVersion, Boolean bUpdateNoVersion, Int32& plID, String& pbstrGuid, Guid pbstrNewDocId, Boolean bHasNewDocId, String bstrVersion, Object& pvarAttachmentNames, Object& pvarAttachmentContents, Object& pvarProperties, Boolean bCheckOut, Boolean bCheckin, Boolean bMigration, Boolean bPublish)
--- End of inner exception stack trace ---
at Microsoft.SharePoint.Library.SPRequest.AddOrUpdateItem(String bstrUrl, String bstrListName, Boolean bAdd, Boolean bSystemUpdate, Boolean bPreserveItemVersion, Boolean bUpdateNoVersion, Int32& plID, String& pbstrGuid, Guid pbstrNewDocId, Boolean bHasNewDocId, String bstrVersion, Object& pvarAttachmentNames, Object& pvarAttachmentContents, Object& pvarProperties, Boolean bCheckOut, Boolean bCheckin, Boolean bMigration, Boolean bPublish)
at Microsoft.SharePoint.SPListItem.AddOrUpdateItem(Boolean bAdd, Boolean bSystem, Boolean bPreserveItemVersion, Boolean bNoVersion, Boolean bMigration, Boolean bPublish, Boolean bCheckOut, Boolean bCheckin, Guid newGuidOnAdd, Int32& ulID, Object& objAttachmentNames, Object& objAttachmentContents, Boolean suppressAfterEvents)
at Microsoft.SharePoint.SPListItem.UpdateInternal(Boolean bSystem, Boolean bPreserveItemVersion, Guid newGuidOnAdd, Boolean bMigration, Boolean bPublish, Boolean bNoVersion, Boolean bCheckOut, Boolean bCheckin, Boolean suppressAfterEvents)
at Microsoft.SharePoint.SPListItem.Update()
at Microsoft.SharePoint.SPAttachmentCollection.AddNow(String leafName, Byte[] data)
at Microsoft.SharePoint.Publishing.Administration.JobReportBase.Update()
at Microsoft.SharePoint.Publishing.Administration.ContentDeploymentJob.importexport_Error(Object sender, SPDeploymentErrorEventArgs errorEventArg)
at Microsoft.SharePoint.Deployment.SPDeployment.OnError(SPDeploymentErrorEventArgs e)
at Microsoft.SharePoint.Deployment.DeploymentLogger.Log(DeploymentLogSeverity severity, SPDeploymentObject deplObject, String message, Boolean throwException)
at Microsoft.SharePoint.Deployment.DeploymentLogger.Log(DeploymentLogSeverity severity, SPDeploymentObject deplObject, Exception exception, Boolean throwNewException)
at Microsoft.SharePoint.Deployment.DeploymentLogger.Log(DeploymentLogSeverity severity, Exception exception, Boolean throwNewException)
at Microsoft.SharePoint.Deployment.SPImport.Run()
at Microsoft.SharePoint.Publishing.Administration.ContentDeploymentJob.DoImport()'

This would be a tricky one to fix...
So I dug deeper into the event log and noticed that a couple of days before, when there were no errors, this service called GetEngineFiles (i.e. ForeFront) had been started. The service was having numerous problems accessing the internet to updated its various scanning engines (because it was a dev machine, and external web access was blocked by the proxy). So I walked over to the infrastructure guys and politely asked 'What the F@#% have you been doing with my server?'. To this they responded 'oh, we installed Microsoft Forefront on it a couple of days ago and configured SharePoint to integrate with it'. So I again politely asked for them to uninstall it and reboot the machine. After this, miracles of miracles, the WCM deployment started working again.
There endith the lesson - Without communication, we would all be lost!