In Windows Server 2012 R2 Windows Update recently decided to stop working and referred me to the WindowsUpdate_80244019 and WindowsUpdate_dt000 error codes.
An answers.microsoft.com thread eventually got to the point and my issue was quickly resolved with an ipconfig /flushdns command at the command prompt.
SharePoint's people picker is generally one of those things that just kind of works—and fairly well no less. There's a gotcha to that statement however: the people picker works well when the the SharePoint farm exists in the same domain as the users you want to match against, or exists in a second domain where a two-way trust has been established with the first domain.
If your SharePoint web frontends exist in another domain with a one-way trust, you've got some extra work to do. This is the case with our dev setup and DMZ setup: our dev VMs are joined to the dev domain which trusts the corporate domain and our production servers are similarly joined to a web domain that also trusts the corporate domain. Both trusts are one-way.
I'll simplify what needs to be done by stating you simply need to tell SharePoint which forests or domains house the users you're after and provide an account from that domain.
Firstly you'll need to provide a key that will be used to encrypt any passwords you plug in during the next step. Run this on every WFE where "key" is a string of your choosing:
STSADM.exe -o setapppassword -password key
Next, set the peoplepicker-searchadforests property:
STSADM.exe -o setproperty-propertyname peoplepicker-searchadforests -propertyvalue <Valid list of forests or domains> -url <URL of the Web application>
where <Valid list of forests or domains> might look like this:
"domain:mydomain.com,mydomain\myuser,mypassword"
Supply the URL of the web application you want to configure (and note you don't need to set this for Central Admin, set it for a specific web application). Multiple domains and forests can be listed if necessary.
For more information, check out these resources:
In the past, we've developed a habit of "birthing" new SharePoint sites in a UAT environment for initial setup and stabilisation before the big move to the production farm; during major site renovations—like the recent www.westernaustralia.com rebrand—we'll implement a quasi-freeze on production (emergency edits only) and conversely pull the content down to UAT for overhaul. At the end of the day, we're moving SharePoint content between farms on a fairly regular basis.
Prior to the release of the April 2009 Cumulative Update packages, Microsoft didn't support moving content databases between farms because "MOSS often stores absolute URLs to the Page Layout in the properties of a Publishing Page." With the April Cu that changes but of course the times they a change too and we've abandoned the stsadm backup/restore commands in favour of restoring SQL Server backups and running the stsadm deletecontentdb/addcontentdb commands (it's not only more reliable but many times faster…).
Until yesterday none of the above was causing us any problems. In fact, we'd even become complacent about it all.
So finding out one of our content editors was unable to publish a page due to a previously unseen exception was not something that would have led us to review the way we handle content databases. After checking out some pages for editing, an attempt to publish the page was met with the following exception:
ArgumentException
Value does not fall within the expected range.
Stack trace: at Microsoft.SharePoint.Library.SPRequestInternalClass.GetMetadataForUrl(String bstrUrl, Int32 METADATAFLAGS, Guid& pgListId, Int32& plItemId, Int32& plType, Object& pvarFileOrFolder)
at Microsoft.SharePoint.Library.SPRequest.GetMetadataForUrl(String bstrUrl, Int32 METADATAFLAGS, Guid& pgListId, Int32& plItemId, Int32& plType, Object& pvarFileOrFolder)
at Microsoft.SharePoint.SPWeb.GetMetadataForUrl(String relUrl, Int32 mondoProcHint, Guid& listId, Int32& itemId, Int32& typeOfObject, Object& fileOrFolder)
at Microsoft.SharePoint.SPWeb.GetFileOrFolderObject(String strUrl)
at Microsoft.SharePoint.Publishing.CommonUtilities.GetFileFromUrl(String url, SPWeb web)
at Microsoft.SharePoint.Publishing.PublishingPage.get_Layout()
at Microsoft.SharePoint.Publishing.PublishingPage.GetEffectivePageCacheProfileId(Boolean anonUserProfile)
at Microsoft.SharePoint.Publishing.PublishingPage.GetEffectiveAnonymousPageCacheProfileId()
at Microsoft.SharePoint.Publishing.CachedPage..ctor(PublishingPage page, SPListItem altItem, String id, String parentId, String title, String url, String description, CachedObjectFactory factory, List`1& fieldInfo, Boolean datesInUtc)
at Microsoft.SharePoint.Publishing.CachedPage.CreateCachedPage(PublishingPage page, SPListItem altItem, CachedObjectFactory factory, List`1& fieldInfo, Boolean datesInUtc)
at Microsoft.SharePoint.Publishing.CachedPage.CreateCachedPage(PublishingPage page, CachedObjectFactory factory, List`1& fieldInfo, Boolean datesInUtc)
at Microsoft.SharePoint.Publishing.CachedListItem.CreateCachedListItem(SPListItem item, SPListItem alternateItem, Boolean parentIsWeb, CachedObjectFactory factory, List`1& fieldInfo, Boolean datesInUtc)
at Microsoft.SharePoint.Publishing.CachedObjectFactory.CreateObject(SPListItem listItem, List`1& fieldInfo, Boolean datesInUtc)
at Microsoft.SharePoint.Publishing.CachedObjectFactory.CreateObject(PublishingPage page, Boolean datesInUtc)
at Microsoft.SharePoint.Publishing.CachedObjectFactory.GetPageForCurrentItem()
at Microsoft.SharePoint.Publishing.TemplateRedirectionPage.ComputeRedirectionVirtualPath(TemplateRedirectionPage basePage)
at Microsoft.SharePoint.Publishing.Internal.CmsVirtualPathProvider.CombineVirtualPaths(String basePath, String relativePath)
at System.Web.Hosting.VirtualPathProvider.CombineVirtualPaths(VirtualPath basePath, VirtualPath relativePath)
at System.Web.UI.DependencyParser.AddDependency(VirtualPath virtualPath)
at System.Web.UI.DependencyParser.ProcessDirective(String directiveName, IDictionary directive)
at System.Web.UI.PageDependencyParser.ProcessDirective(String directiveName, IDictionary directive)
at System.Web.UI.DependencyParser.ParseString(String text)
at System.Web.UI.DependencyParser.ParseFile(String physicalPath, VirtualPath virtualPath)
at System.Web.UI.DependencyParser.GetVirtualPathDependencies()
at Microsoft.SharePoint.ApplicationRuntime.SPVirtualFile.CalculateFileDependencies(HttpContext context, SPRequestModuleData basicRequestData, ICollection& directDependencies, ICollection& childDependencies)
at Microsoft.SharePoint.ApplicationRuntime.SPDatabaseFile.EnsureDependencies(HttpContext context, SPRequestModuleData requestData)
at Microsoft.SharePoint.ApplicationRuntime.SPDatabaseFile.EnsureCacheKeyAndViewStateHash(HttpContext context, SPRequestModuleData requestData)
at Microsoft.SharePoint.ApplicationRuntime.SPDatabaseFile.GetVirtualPathProviderCacheKey(HttpContext context, SPRequestModuleData requestData)
at Microsoft.SharePoint.ApplicationRuntime.SPVirtualFile.GetVirtualPathProviderCacheKey(String virtualPath)
at Microsoft.SharePoint.ApplicationRuntime.SPVirtualPathProvider.GetCacheKey(String virtualPath)
at Microsoft.SharePoint.Publishing.Internal.CmsVirtualPathProvider.GetCacheKey(String virtualPath)
at System.Web.Compilation.BuildManager.GetCacheKeyFromVirtualPath(VirtualPath virtualPath, Boolean& keyFromVPP)
at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile)
at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile)
at System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory(VirtualPath virtualPath, HttpContext context, Boolean allowCrossApp, Boolean noAssert)
at System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath virtualPath, Type requiredBaseType, HttpContext context, Boolean allowCrossApp, Boolean noAssert)
at System.Web.UI.PageHandlerFactory.GetHandlerHelper(HttpContext context, String requestType, VirtualPath virtualPath, String physicalPath)
at System.Web.HttpApplication.MapHttpHandler(HttpContext context, String requestType, VirtualPath path, String pathTranslated, Boolean useAppConfig)
at System.Web.HttpApplication.MapHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
Which of course means nothing.
Before long the guys stumbled across one of Stefan Goßner's brilliant posts, which suggests MOSS doesn't update all absolute page layout URLs on each publishing page object when content is shifted between farms; of cours, with the April 2009 CU installed and doing things via backup/restore or import/export, we may have avoided this issue.
You can see the exact problem by examining a page in SharePoint Manager: locate a page in the Pages library, expand the page node to reveal its Properties node, and expand the Properties node so you can inspect the PublishingPageLayout node. This screenshot is from my development environment, a server named dev-moss-mh5 and the wa.com web application configured to run on port 180—so obviously the http://edit.uat.westernaustralia.com value is incorrect:
Interestingly, this problem was only affecting the production edit site… for whatever reason, my dev environment was unaffected. However, running Stefan's FixPageLayout code corrected the problem in production. The application runs through every page in every subsite and fixes the PublishingPageLayout property where required (in addition to reporting any other page instance/layout/master page issues).
Update: Just remembered from a while back Gary Lapointe also has an stsadm command to fix this problem:
http://stsadm.blogspot.com/2007/08/fix-publishing-pages-page-layout-url.html
We've run a post-deployment script in our SharePoint environment for many years now to address a 403 Forbidden error that otherwise plagues us; the script grants the Authenticated Users account read access on the web application's bin directory and web.config file (for both the authenticated and anonymous sites).
Someone deemed this necessary back in the day and, until recently, I always assumed it was just some quirk with our crusty environment. That was until I came across the same problem at another client site where custom code (in a SharePoint solution) was being deployed.
With that as motivation, I decided to figure out why we do what we do and determined a .NET 2.0 security update from July 2007 introduced the problem:
The performance of the server may decrease and adding users or uploading files may fail with the error message "403 Forbidden error" after you install a Microsoft .NET Framework 2.0 hotfix.
The security update links to a SharePoint 2007 hotfix:
In SharePoint Server 2007, the performance of the server may decrease, and you cannot upload files or add users. Additionally, you may receive the following error message:
403 Forbidden error
This issue occurs after you install a Microsoft .NET Framework version 2.0 hotfix that is build 2.0.50727.832 or a later build.
In the www.westernaustralia.com context, the problem normally crops up when an anonymous user requests a page that runs custom code; with my second client, the problem occurred in the authenticated site when a content editor with full permission over the site collection attempted to access a SharePoint list. The 403 response seemed to be intermittent but I suspect it was application recycles correcting the problem for a short while. As a user with local admin rights on the WFE, I wasn't seeing the problem myself.
Apparently uninstalling the update may be an option but I wonder if it's been incorporated into .NET 3.5 so that may not be possible in this day and age.
Anyway, the consensus around this problem is that it's caused when a request from an authenticated user without local admin rights results in a failed read of the /bin directory by the impersonating w3wp.exe process (as evidenced by filemon.exe). The solution is to ensure the Authenticated Users group has read access to the /bin directory below C:\inetpub\wwwroot\wss\VirtualDirectories\{your app}
Notably, we've found this permission needs to be reapplied as part of every deployment and often find permissions have reset after touching the Authentication providers settings in Central Admin.
A web site user rang the support desk to complain a thumbnail image of theirs wasn't displaying on our web site. We asked them to send a screenshot of the problem; this is what we got back (names altered to protect the bright sparks involved):
From: Best Resort [mailto:visit@bestresort.com]
Sent: Thursday, 15 July 2010 12:40 PM
To: 'Carol Belding'
Subject: Best Resort Broken Image
Hi Carol
Printed and scanned page for you.
Regards
Fran
Best Resort
If you’re shunting SharePoint content databases around between environments using the stsadm deletecontentdb and addcontentdb commands, you may find a couple of new errors in your events logs:
Failure trying to synch web application {guid}, ContentDB {guid} Exception message was A duplicate site ID {guid}(http://yoursite) was found. This might be caused by restoring a content database from one server farm into a different server farm without first removing the original database and then running stsadm -o preparetomove. If this is the cause, the stsadm -o preparetomove command can be used with the -OldContentDB command line option to resolve this issue.
followed by:
A runtime exception was detected. Details follow.
Message: A duplicate site ID {guid}(http://yoursite) was found. This might be caused by restoring a content database from one server farm into a different server farm without first removing the original database and then running stsadm -o preparetomove. If this is the cause, the stsadm -o preparetomove command can be used with the -OldContentDB command line option to resolve this issue.
After restoring a production content database to my dev environment, I was finding these two errors every hour on the dot.
Importantly—and despite what this error message notes as a possible cause—Todd Carter details why you shouldn’t be using stsadm preparetomove in a modern (post-IU) SharePoint environment. It seems like preparetomove actually fixed up some GUIDs before a detach/attach operation and it’s still documented with no warnings on Technet but hey, there’s something to be said for collective community wisdom when it comes to Sharepoint ;)
The problem itself seems to lie with SharePoint’s inability to update database IDs during the detach/attach process and (possibly) the fact the content database consumes an SSP. I’m a bit unclear on how the Infrastructure Update may have addressed this but at the end of the day I just want a clean event log and stable environment.
To correct this problem and clear both error messages, I ran the following stsadm command:
stsadm –o sync –DeleteOldDatabases 0
Despite it’s name, the DeleteOldDatabaes parameter doesn’t delete databases, only the “old records corresponding to these databases.” The zero value instructs the command to delete all records that have not been synchronized for the specified number of days. For a report of what might be cleaned up, run stsadm –o sync –ListOldDatabases 5 first.
With everything working admirably in development I was greeted with the below error message when attempting to create a new page after today’s fresh deploy to UAT (and eventually prod, where I gave up):
Error No parameterless constructor defined for this object
No fun but luckily the problem was easily isolated and a work around arrived at—although I have yet to unearth the root cause.
By way of more detail, I was attempting to create a new page instance in a new sub site using a branded master page and page layout. This isn’t normally a problem and seems to be limited to this master page/layout combo as I can successfully create page instances in the same sub site using another layout known to be good. The problematic page layout contains a single rich text field and webpartzone but, unlike other posts discussing the same error message, the <zonetemplate> element is empty and I’m not attempting to deploy web parts to the page using the AllUsersWebPart crappiness. I just want my basic page!!
Most of the suggestions out there for resolving the above error lead you to the web part editor maintenance screen (see below) where you’ll find one or more ErrorWebParts, which can then be deleted. The problem with this approach is maintaining the page’s web parts requires the page layout to be checked out and that customises the layout, meaning future feature-based deployments of that layout won’t “take”. Of course, my layout isn’t supposed to have any web parts so go figure where the single mysterious ErrorWebPart originates… there seems to be a (related?) issue accessing web part programmatically in which ErrorWebParts objects are returned instead so I wonder if this is a different web part than how it’s represented…
Others suggest redeploying the layout after deleting it from the gallery but that didn’t work in my case.
In the end, I created a page from a different layout using the same content type as my desired page and then changing the layout. All fine from there but not at all usable—luckily this was for a short-lived campaign site.
How to open a page layout in web part maintenance mode
Just as a page instance can have web parts, a page layout can also have web parts. To manage those web parts, check out the layout within the Master Page Gallery, and click View Properties from the context menu. Next, edit the item and click the ‘Open Web Part Page in maintenance view’ link at the bottom of the page.
Alternatively, you can substitute your page layout in this URL:
http://<server>/_catalogs/masterpage/<page layout name>.aspx?contents=1
After some more hacking around with a custom list SharePoint gave me this error code: 0x81070215
Basically I’d mangled a list definition while an earlier version of the list still existed. The easy solution in my case (dev) was to simply fire up SharePoint Manager 2007 and use the UI to delete the offending list (stsadm –o forcedeletelist –url http://spsite would have probably done the same thing). In a more serious environment, you’d probably need to redeploy the list bits as they were when the list was created.
One of the first things I normally do after creating a new web application and site collection is backup the content database using stsadm -o backup. If you're running in a least privilege scenario, however, there's an extra step required to configure access to the content database.
Whenever I'm working interactively with MOSS in an administrative capacity, I'm logged in as the MOSS setup account. This is the account used to install MOSS and create the farm; it’s also a member of the local admin and WSS_ADMIN_WPG groups, a member of the Farm Administrators group, and I've even got it configured as the primary site collection administrator for my content databases. In general, this account gives me the permissions I need to do everything I need to do while keeping my MOSS install functional.
Despite the wealth of permissions granted to this account, I was surprised when I tried running the stsadm -o backup command and came up against this error:
Cannot open database "WSS_Content_APP" requested by the login. The login failed.
Login failed for user 'domain\moss_setup'.
A similar, dodgier message was echoed in the Application event log.
To work around this, the setup account must be added to the db_owner role of the content database being backed up:
Navigate to the {WSS_Content DB}\Security\Roles\Database Roles\db_owner role and view its properties
Add the Setup account (eg. domain\moss_setup) as a Role Member
I've found no other role will suffice. Note in a least privilege scenario, the setup account should not be a member of the local admin group on the database server.
I'd love to know how to do this automatically whenever a new content database is added although I can understand why MOSS doesn’t do this for me… sort of ;-)
While attempting to run the stsadm -o backup command as the MOSS setup user for the first time in a new environment today, I came across an error message in the application event log:
Event Type: Error
Event Source: Windows SharePoint Services 3
Event Category: Database
Event ID: 3760
Description:
SQL Database 'WSS_Content_APP' on SQL Server instance 'MOSSSQL' not found. Additional error information from SQL Server is included below.
Cannot open database "WSS_Content_APP" requested by the login. The login failed.
Login failed for user 'domain\moss_setup'.
I wasn't careful when I first read the message and only read the first line. As MOSSSQL is actually a SQL Server alias to a physical server and this is the first time I've used aliases, I initially wondered if the backup command or stsadm was unable to deal with alias. That's silly, of course, because I've never told MOSS which physical server is underlies the alias and it only knows about the alias.
I'm not sure exactly how MOSS and SQL together track down the WSS_Content_APP database but the crux of this error message lies in the second part as flagged by SQL Server. In my case, the moss_setup account required access to the content database--but that's another blog post.
