For my Document Library WorkflowAssociations.Count is zero.
For this document Library EnableModeration is false.
Still I can see column in the document Library named "Approval Status". (internal name "_ModerationStatus")
When I try to set EnableModeration true for this document library , I get exception.
Seems to be some time in the past workflow was enabled on this list / enablemoderation was true . But setting these to negative did not remove Approval Status column.
How I can fix this document library without deletion , so that future workflows enabled or enablemoderation=true should not give exception ?
• On web application management ( e.g. http://ServerName:CentralAdminPort/_admin/WebApplicationList.aspx) page under central admin , go to Permission Policy :
• Mark the check box which says deny users to view application pages and save.
• Output is :
• Now go to user policies tab for main web application and click on add user :
• Select the zone on which public main application is deployed :
• Under people picker type "ASP.NET Membership provider name" , Permissions : Deny System Pages and click finish :
• Output is like :
Now access few application pages and lists directly to verify with a form authentication user .
Alternative approach and suggestions are welcome under comments section.
On page http://ServerName/_Layouts/VariationLogs.aspx , when I ran Timer Job "Variations Create Hierarchies Job Definition" , I was getting the error ( Under Failures column) :
The Variations Create Hierarchies job failed with the following error message: <nativehr>0x80070057</nativehr><nativestack></nativestack>.
I was getting below mentioned errors in ULS logs :
Process : OWSTimer.exe Area : Web Content Management Category : Site Management Level : Unexpected
Process : OWSTimer.exe Area : Web Content Management Category : Site Management Level : Unexpected
PublishingWeb::CreateVariationsDeepForCurrentPages caught Exception at item 'Pages/Folder1/Folder2/PageName.aspx' with : <nativehr>0x80070057</nativehr><nativestack></nativestack>
Process : OWSTimer.exe Area : Web Content Management Category : Publishing Level : Monitorable
GetFileFromUrl: ArgumentException when attempting get file Url http://OldServerName/_catalogs/masterpage/PageLayoutFileName.aspx <nativehr>0x80070057</nativehr><nativestack></nativestack> 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.GetFileOrFolderObject(String strUrl) at Microsoft.SharePoint.Publishing.CommonUtilities.GetFileFromUrl(String url, SPWeb web)
Process : OWSTimer.exe Area : SharePoint Foundation Category : General Level : High
Process : OWSTimer.exe Area : Web Content Management Category : Site Management Level : Unexpected
PublishingWeb::CreateVariationsDeepForChildPages() caught Exception at web 'http://NewServerName/es-LA/Subsite1' with : <nativehr>0x80070057</nativehr><nativestack></nativestack>
Process : OWSTimer.exe Area : Web Content Management Category : Site Management Level : Unexpected
DeploymentWrapper::CreateVariantPage() on sourcePage = 'Pages/Folder1/Folder2/PageName.aspx', targetWeb = 'http://NewServerName/es-LA/Subsite1' catches an unexpected exception: System.ArgumentException: <nativehr>0x80070057</nativehr><nativestack></nativestack> 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.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.set_Layout(PageLayout value) at Microsoft.SharePoint.Publishing.Internal.DeploymentWrapper.CreateVariantPage(PublishingPage sourcePage, PublishingWeb targetArea, String destPageWebRelativeUrl, String pageLayoutName, String title, String description, Boolean copyResources, Boolean enforceMajorVersion, SPWeb& webToClose, PageLayout[] targetAreaAvailablePageLayouts).
Possible Reason :
1. You have recently moved your content db from an old server , the display names for page layouts seems to be updated ( even on mouse hover) but internally older server name is being referred. 2. Even after updating page layout via object model , publishing cache is not flushed. Possible Resolution:
1.
For all the Publishing pages under source variation , update property "PublishingPageLayout" to http://NewServerName/_catalogs/masterpage/PageLayoutFileName.aspx [ old value http://OldServerName/_catalogs/masterpage/PageLayoutFileName.aspx ] page.ListItem.Properties["PublishingPageLayout"] = newPageLayout;
2. Flush object cache at http://ServerName/_Layouts/objectcachesettings.aspx 3. IISRESET 4. Restart owstimer.exe 5. Under http://ServerName/_Layouts/VariationLabels.aspx again schedule create Hierarchies. 6. Have a cup of tea. 7. Start the Timerjob 'Variations Create Hierarchies Job Definition’ manually or wait for the schedule. 8. Keep an eye on http://ServerName/_Layouts/VariationLogs.aspx
Except Chinese version I am able to access Pages Library Like :
web.Lists["Pages"] or web.Lists.TryGetList("Pages") .
But for Chinese sub site :
If I Iterate web.Lists collection using foreach loop , there is a list present whose SPList.Title is "Pages" . For this list Under SPList.SchemaXml , Title is Title="頁面"
web.Lists["Pages"] gives error: List 'Pages' does not exist at site with URL 'XXXXXXXXXXXXXXXXXXXXXXXXX' AND web.Lists.TryGetList("Pages") gives null .
But web.Lists["頁面"] returns the right SPList object
Is it like , SharePoint API's to retrieve a list by name refer to SchemaXml rather than SPList.Title , while retrieving a list internally ?
Reply 1 by http://social.technet.microsoft.com/profile/ivan%20vagunin/?ws=usercard-mini
Hi!
I would propose to use SPWeb.GetList function - it returns list by url (eg web.GetList("/myweb/Pages") and url usually the same for all locales.
We have a staging source and target production. For 1st migration on blank site collection :
1. Even if we migrate content to a blank site collections we get many warnings like :
a.
[WebFeature] [Publishing] Warning: Provisioning did not succeed. Details: Failed to create the 'Images' library. OriginalException: The feature failed to activate because a list at 'PublishingImages' already exists in this site. Delete or rename the list and try activating the feature again.
b.
Warning: Provisioning did not succeed. Details: Failed to create the 'Images' library. OriginalException: The feature failed to activate because a list at 'PublishingImages' already exists in this site. Delete or rename the list and try activating the feature again.
c.
Warning: User or group 19 cannot be resolved.
Can we use a backup of staging as target instead of blank . What else than initial migration failure should I aspect as drawback in this ?
2.
Content deployment deploys the most recent major and minor versions of a content item. For example, if version 2.7 of a Web page is being deployed, the most recent major version (2.0) of the page, and the most recent minor version (2.7), will be deployed to the destination site.
Is it possible to limit the migration to last major version only ?
We have started with blank site collection using powershell. Still getting the error in point one.
I refer to http://centralAdmin/_admin/Deployment.aspx in this problem statements above.
In the section about the requirements for a successfuly content deployment, he recommends using an empty site collection for the destination and not a site collection with the Blank Site template (STS#1):
3) Use an empty site collection as the destination of your content deployment job
As already discussed in Part 5 content deployment will fail if the destination database contains conflicting content. To avoid this it is required that the initial deployment is done into an empty site collection.
Be aware that the only way to create an empty site collection is to use the following STSADM command:
Using the "Blank Site" template will NOT create an empty site collection! It will actually create a site collection with content. You can see the difference if you create a site collection using both methods and then inspect the content of the created sites using SharePoint designer.
I personally recommed to always use the STSADM command with the syntax above to ensure that you really have an empty site collection as destination.
Impact: If the site collection has been created using a different method or already contains data the content deployment job will fail.
How to resolve: Deploy into an empty site collection
For your second question, content deployment will deploy the latest published version. If you don't want a minor version to be deployed (it's a draft, perhaps), simply do not publish it.
Reply 2 By http://social.technet.microsoft.com/profile/neal%20mcfee%20%5Bmct%5D/?ws=usercard-mini
To create a site collection that does not have a template (an empty site template) you omit the -template parameter in the New-SPSite cmdlet.
If you create a blank site using the STS#0, this will not work for the task you are trying to complete.
Try deleting the target site collection and recreating it using New-SPSite but do not specify the template.
Then re-run your publishing job.
If this helps you then please mark the post as helpful. If this answers your question then mark it as the answer. If another contributor in the thread answers your question then please do the right thing. And as always most answers for SharePoint are based on "It depends"
variationsfixuptool is used to correct variations system data
on publishing sites or pages.If you want to analyze the actual site structure
and the data stored in the relationships list this tool may be good one.
Syntax
stsadm -o variationsfixuptool
-url <source variation site URL>
[-scan]
[-recurse]
[-label]
[-fix]
[-spawn]
[-showrunningjobs]
Parameters
Parameter name
Value
Required?
Description
url
A valid URL, such as http://server_name
Yes
The URL of a site in source variation where variations system data is being analyzed or corrected.
scan
<none>
No
Analyzes the variations hierarchy and report findings.
This parameter provides functionality that cannot be accessed using the Central Administration Web site.
For each Site/Page, it reports:
If the source site is marked as being in the source variation hierarchy (SPWeb.AllProperties["__InSourceHierarchy"] == True ?). If the site is marked as being in the source hierarchy means that the page is part of the source hierarchy.
The Variation Group Id of the source site or page (SPWeb.AllProperties["Variation Group Id"] or PublishingPage.ListItem[FieldId.VariationGroupId])
Which peers are registered in the relationships list with same Variation Group Id
If a variation peer exists in the configured labels (default is all spawned labels) by first checking if a peer is configured in the relationships list with the same variation group ID for the given label. If no peer can be found using the relationships list we try to lookup the peer using the default URL that would be used when creating a variant in the given label
The variation group id of the variation peers in the target labels (SPWeb.AllProperties["Variation Group Id"] or PublishingPage.ListItem[FieldId.VariationGroupId])
If the source site/page is configured in the relationships list
In addition the command reports the variation labels used for the peer check (default is all spawned labels).
The tool will not identify any issues - it is required to analyze the report in detail and interpret it in order to find problems.
recurse
<none>
No
Scan or fix all subsites of the site specified by the url parameter.
label
A valid label name, such as "English"
No
Name of the label of the variation target.
fix
<none>
No
Corrects invalid variations system data that are found. If the recurse parameter is used, fixes are done
recursively for all subsites.
This parameter provides functionality that cannot be accessed using the Central Administration Web site.Fix mode will not create missing variation peers.
The following issues are automatically fixed:
Missing Variation Group ID on source site or source page
Missing relationships list entry for source or target page or site
Missing Variation Group ID on target site or target page
Different Variation Group ID in source site/page and target site/page (source ID will win)
spawn
<none>
No
Creates new site variations on the source variation site specified by the url parameter for all target variations labels. If the recurse parameter is used, variations for subsites and pages are also created.
This parameter equivalent to the New Variation Site user interface setting that is located on the Site Content and Structure page.
This operation mode cannot be used to spawn pages in already spawned sites.
The command initiates the site spawn operation by creating a scheduled work item for the SpawnSiteJobDefinition timerjob. The spawn will be performed as soon as the timerjob runs.
The difference between the scheduled work item created by the CPVAreaEventReceiver and the Variationsfixuptool is that the tool has the option to create a workitem, which only spawns the site to one specific variation rather than to all spawned variation labels.
A common use scenario is to configure the source variation label with the Hierarchy Creation option to create only the root site and not the complete hierarchy and later to spawn the hierarchy or parts of the hierarchy from the source label using the STSADM command.
In MOSS 2007, this command was a major benefit compared to the automatic hierarchy creation in the UI, as it was the only way to force the creation in OWSTIMER rather than W3WP.
With SharePoint 2010 where all actions are already in OWSTIMER the benefit of using the STSADM command rather than the UI is rather limited.
showrunningjobs
<none>
No
Displays current status of Variations Propagate Page Job Definition and Variations Propagate Site Job Definition timer jobs that are located on the Timer Job Status page of the SharePoint Central Administration Web site. But this does not provide information about Variations Create Hierarchies Job Definition , Variations Create Page Job Definition and Variations Create Site Job Definition.You only get to know about Variations Propagate Page Job Definition and Variations Propagate Site Job Definition.
under the "System" Group > "Keywords" Termset I can see various terms which are named as various combination of digits like :
1,2,3,4,5,6
1,2,3,6,4,5
1,2,5,6,4,3
1,3,4,2,5,6
1,3,5,2,4,6
1,3,6,2,4,5
1,4,2,3,5,6
1,4,3,6,2,5
1,5,2,3,4,6
1,5,2,3,6,4
1,6,2,3,4,5
If you know why they are there , kindly share this with all of us.Please explain what is the purpose of these digits ( Enterprise Keywords) , I we loose few of them , what may be the consequences.
The source of the question is , one of our servers is having few extra of them like : 18,19,20,21,22,23
Reply 1
Hello,
I checked and I wasn't able to reproduce this issue by Content Deployment between 2 SharePoint environments so this seems like an environment specific issue; in-depth engagement is not feasible thru forum replies and this issue requires a more in-depth level of support. Please visit the below link to see the various paid support options that are available to better meet your needs:http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone. If you are a MSDN / TechNet subscriber, you can also contact our support by using your free support incidents.
However, other members of the community may still have encountered the issue you're seeing, and have a solution to offer!
The keywords visible under "System" group are added by tagging documents / list items with predefined (taxonomy) and user defined (folksonomy). There are no pre-populated digit keywords so I do not believe there would be impact other than tagged items losing these tags.
if staging has a dummy term and corresponding TaxonomyHiddenList entry . The Content deployment /migration from staging to production create such type of terms.
What Microsoft can do to fix it :
1. Suppose staging has a term (myGuid) under Termset1(Guid1), under Group1 ( Guid2) , under Store 1 ( Guid3 ); and while migration of site collection it finds a term in taxonomyhiddenlist which is missing on target >
2. It should search for Guid1 under GUID2 under GUID 3 to create a term with myGuid.
As of now under current implementation by Microsoft for migration API's it seems to be creating entry under Group System Termset Keywords.
