$contentType = $spWeb.ContentTypes[$reportingServicesCT]

if($contentType.RequireClientRenderingOnNew -eq $true)

{

$contentType.RequireClientRenderingOnNew = $false

$contentType.Update()

Write-Host $contentType.Name "updated (web level)" -ForegroundColor Yellow

}

else

{

Write-Host "No update needed for (web level): " $contentType.Name

}

$docLib = $spWeb.Lists[$docLibName]

$docContentType = $spWeb.ContentTypes[$reportingServicesCT]

if($docContentType.RequireClientRenderingOnNew -eq $true)

{

$docContentType.RequireClientRenderingOnNew = $false

$docContentType.Update()

Write-Host $docContentType.Name "updated (DocLib level)" -ForegroundColor Yellow

}

else

{

Write-Host "No update needed for (DocLib level): " $docContentType.Name

}

Matthieu RUNTZ

I recently had to assist a customer to migrate some content databases from a SharePoint 2010 environment to a SharePoint 2013 environment.

The source environment:

• Windows Server 2008 R2
• SharePoint Server 2010 (with Reporting Services 2008 R2 Add-in)
• SQL Server 2008 R2
• Reporting Services 2008 R2 (SharePoint Integrated mode)

The destination environment:

• Windows Server 2012 R2
• SharePoint Server 2013 (with Reporting Services 2012 Add-in)
• SQL Server 2012
• Reporting Services 2012 (SharePoint Integrated mode)

The migration was done by using the Content Database detach/attach procedure. Before attaching the database to the new environment we executed “Test-SPContentDatabase” and get the following error:

WebPart class [ab6d9dad-e23c-ce4f-ff98-f6575a1ccf4c] (class [
                  Microsoft.ReportingServices.SharePoint.UI.WebParts.ReportView
                  erWebPart] from assembly
                  [Microsoft.ReportingServices.SharePoint.UI.WebParts,
                  Version=10.0.0.0, Culture=neutral,
                  PublicKeyToken=89845dcd8080cc91]) is referenced [4] times in
                  the database [WSS_Content], but is not installed on
                  the current farm. Please install any feature/solution which
                  contains this web part.

The Microsoft.ReportingServices.SharePoint.UI.WebParts in version=10.0.0.0 is reported as missing because this WebPart is brought by the Reporting Services 2008 R2 Add-in which is a version that is not supported on a SharePoint 2013 environment. On the destination environment, the Reporting Services 2012 Add-in was deployed and the version of the WebPart that was added to the GAC is 11.0.0.0.

If you ignore the warning and attach the database to the SharePoint 2013 environment, when a user access to a page containing a Reporting Service WebPart, the WebPart will not be visible and the following error will be logged in the ULS logs:

An unexpected error has been encountered in this Web Part.  Error: A Web Part or Web Form Control on this Page cannot be displayed or imported. The type Microsoft.ReportingServices.SharePoint.UI.WebParts.ReportViewerWebPart, Microsoft.ReportingServices.SharePoint.UI.WebParts, Version=11.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91 could not be found or it is not registered as safe

In order to allow the user to view the reports displayed via the ReportingServices WebPart, the WebPart references on the pages need to be updated in the SharePoint 2013 environment. This update consists in replacing the version 10.0.0.0 of the WebPart by the version 11.0.0.0.

Two options allow to do the update:

• On the SharePoint 2013 environment remove the old WebParts and add instances of the new version of the WebPart (then reconfigure the WebParts).
• On the SharePoint 2010 environment, update the references of the Reporting Services WebParts to reference the version 11.0.0.0 instead of the version 10.0.0.0.

Option n°1

The first option consists in attaching the Content Database to the SharePoint 2013 environment (warnings are ignored), and remove the references to WebParts in version 10.0.0.0, then to add the new version of the WebParts and reapply the same configuration as for the WebPart that was removed.

1. Restore a SQL Server Backup of the Content Database to migrate on a test environment

2. On this database, execute the following query: select * from WebParts WITH (NOLOCK) where tp_WebPartTypeId = 'ab6d9dad-e23c-ce4f-ff98-f6575a1ccf4c'

3. For each result returned, execute the following query after updating the value of tp_PageURLID in order to find the URLs of the pages containing Reporting Service WebParts : select * from AllDocs WITH (NOLOCK) where id = '<tp_PageURLID>'

4. Migrate the Content Database to SharePoint 2013 environment by using the database detach/attach method

5. On the SharePoint 2013 environment connect to all URLs identified previously. Add at the end of the URL “?contents=1” in order to be able to remove the old version of the WebPart, then add again the WebPart to the page, and apply the same configuration as previously, finally check the page in.

Option n°2

The second option consists in updating the references of the Reporting Services WebParts in the SharePoint 2010 environment, then to detach/attach the Content Database to the SharePoint 2013 environment.

1. Installation of the SQL 2012 Reporting Services Add-in on the SharePoint 2010 environment

After installation of the Add-in the following elements are added to the Web.config of the Web Applications:
<SafeControl Assembly="Microsoft.ReportingServices.SharePoint.UI.WebParts, Version=11.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91" Namespace="Microsoft.ReportingServices.SharePoint.UI.WebParts" TypeName="*" Safe="True" />

<dependentAssembly xmlns="urn:schemas-microsoft-com:asm.v1">
        <assemblyIdentity name="Microsoft.ReportingServices.SharePoint.UI.WebParts" publicKeyToken="89845dcd8080cc91" culture="neutral" />
        <bindingRedirect oldVersion="10.0.0.0" newVersion="11.0.0.0" />
</dependentAssembly>

The dependentAssembly section allows to specify that the DLL in version 11.0.0.0 must be loaded when the version 10.0.0.0 is called.

2. In order to update the references to the Reporting Services WebParts in the Content Database, it is needed to do a check-out / check-in on all pages containing this WebPart. To identify the pages, you can use the same steps as described in the option n°1.

3. Detach the database from the SharePoint 2010 environment and attach it to the SharePoint 2013 environment.

Warning: If in you Content Database you have multiple versions of the pages containing the Reporting Services WebPart, the Test-SPContentDatabase command will continue to display warning as the old version of the WebPart will still be referenced in the older versions.

Thanks to Dominique VIVES for having reviewed my post.

Matthieu RUNTZ

The problem is that the External User account gets, somehow, associated with a different UPN in the Users List of SharePoint Online or gets corrupted somehow. Either way the first thing to do is to find it and get rid of it so that we can recreate a health account in the Users List.

I had like to mention that I have seen cases where the Administrator has executed the command Get-SPOExternalUser in the Power Shell Administration console but the External User account was not found using this method.

The solution in this case was to look for the External User account in the Users List page:

<URL>/_layouts/15/people.aspx?MembershipGroupId=0

If the account appears listed in there, just delete it and then re-invite the user. This time around it should work.

I hope this works for you, when facing a similar problem.

Helio De Andrade

"The column "Workflow History Parent Instance" in the list or library "CreateDateExpiredTasks History" has been marked for indexing. Please turn off all indexed columns before changing the collation of this site. You may re-index those columns after the collation of the site has been changed."

Or

"The column "Invitation" in the list or library "correlation ID number" has been marked for indexing. Please turn off all indexed columns before changing the collation of this site. You may re-index those columns after the collation of the site has been changed."

Or 

"The site regional settings cannot be changed because one or more columns has been marked for indexing".

 You could try to get rid of the afore mentioned column manually but that could take hours on a medium to large site.

 The best way I have found so far to be able to change the Regional Settings under this condition is to make sure the "Sort Order" option is set to "General", as in this screen-shot:

I hope this help.

Thanks to Dominique VIVES for having reviewed my post.

Helio De Andrade

• If you use Yammer Basic, the free version of Yammer, you don't need to activate Yammer.
• You need to activate Yammer if you paid for Yammer Enterprise which is available online with the following plans :
  • Yammer Enterprise Standalone
  • Office 365 Enterprise Plans
  • Office 365 Midsize Business
  • SharePoint Online + Yammer Enterprise Plans
  • Office 365 Education Plans

   

For more details: https://about.yammer.com/success/activate/activation-guide/why-yammer/

2. Where do you activate Yammer?

As part of Yammer Enterprise, you receive access to your own Office 365 Admin Portal with a Global Admin account. Use this portal to configure your account and activate your Yammer Enterprise network.

3. What are Yammer activation prerequisites?

Yammer requires a company domain, such as contoso.com to activate the network. This means the default domain (contoso.onmicrosoft.com) you created with your Office 365 account can't be used to activate Yammer Enterprise. So, if you don't have a company domain, you can purchase one from a domain name registrar (for example GoDaddy.com, Gandi.net, etc.), or on the Domains page in O365 Admin portal.

If your enterprise domain is already created, you'll need to have access to your DNS hosting provider or domain registrar to confirm ownership of this domain.

For more details: Add a Company Domain

4. How to activate Yammer?

1. Create your enterprise domain (for this lab, I created imenbacha.com domain).

    

2. Log into your Office 365 Admin Center and go to Domains > Add a domain.

   

    

3. Add your domain

   

    

4. Confirm that you own the specified domain

   

    

5. You are redirected to the site where you created your domain to confirm the ownership of this domain. You'll need to have access to your DNS hosting provider or domain registrar.

   

    

   

    

6. Once the ownership confirmed, you can add users immediately or later.

7. Define how you'll use your domain by selecting Yammer or a combination with other Office 365 services like Exchange Online or Lync Online.

8. Set up DNS records for your enterprise domain at your DNS hosting provider

9. If this domain is your organization's primary domain, change your default Office 365 domain from onmicrosoft.com to the company domain you just added. Go to Admin > Office 365, click your organization name in the upper-right corner, and then choose Default domain.

10. If you choose to manage user accounts in Office 365, you should create a new user in this newly configured domain (for example johndoe@imenbacha.com) and assign it "Global admin". He will automatically be Yammer administrator.

Create a new user in the new domain:

12. Now you are ready to activate Yammer in O365 Admin center!

To do this: Office 365 Admin Site > Dashboard > Included Services > Yes, activate Yammer Enterprise for my network

You can now see Yammer Admin Link:

Note: Your account is Global Admin in O365 Admin center, so it will automatically be Yammer Admin. However you should explicitly create your Yammer profile.

14. Click on: Don't have an account? Sign Up

15. When you signup, you will receive an email in order to complete registration. Click on "Complete Signup":

To access Yammer's administration menu, click on "Network Admin"

19. Now you can use your enterprise social network.

Thanks to Hélène Lemontvert & Dominique VIVES for having reviewed my post.

Imen Bacha

Version : Microsoft Office 365 Plan E3

Date : 25/09/2014

As we all know we have multiple flavors of PowerPivot for SharePoint and sometimes it's a bit strange how you install updates for PowerPivot.

Let us start with the beginning J We have SharePoint 2010 that can use PowerPivot from SQL 2008 R2 or PowerPivot from SQL 2012 SP1/SQL 2014 and on the other hand we have SharePoint 2013 that can use only PowerPivot from SQL 2012 SP1/SQL 2014. I'm grouping SQL 2012 SP1 and SQL 2014 because from the update perspective they are behaving identical.

Situation 1: SharePoint 2010 with PowerPivot from SQL 2008R2

You are installing an update for SQL 2008 R2 like SP2 due to the fact that you need to have your environment supported (SQL 2008 R2 is out of main support starting with 08/07/2014 and the least supported version is SQL 2008 R2 SP2). You can download SP2 and the latest Cumulative Update for it (CU 13) from Update Center for Microsoft SQL Server

In order to upgrade the PowerPivot service application and its components all you have to do is to install the updates and check the Health Analyzer that it picked up the correct version. As explained in the following article Upgrade (PowerPivot for SharePoint), here are the steps to do it:

1. Install the patch using the instructions that are provided with the QFE.
2. In Central Administration, in Monitoring, click Review rule definitions.
3. In the Configuration category, find an then click the following rule:

PowerPivot: The deployed farm solution is not up-to-date

1. In the Health Analyzer Rule Definitions box for this rule, click Run Now.
2. Reset IIS to ensure the older version is no longer available. To do this, open an Administrator command prompt and type IISRESET.

Situation 2: SharePoint 2010 with PowerPivot from SQL 2012 SP1/ SQL 2014

Now we start to have some fun! While for SQL 2008 R2 all you had to do was to install the hotfix (QFE) with PowerPivot 2012 SP1 the situation has changed and be careful you should install the x64 hotfix as SharePoint and PowerPivot for SharePoint are only on x64.

Please check the articles describing procedure:

Upgrade PowerPivot for SharePoint (SQL 2012 SP1)

Upgrade PowerPivot for SharePoint (SQL 2014)

• Once you have installed the hotfix/CU you will need to run the PowerPivot Configuration Tool as now it's like applying a hotfix for SharePoint (install windows binaries and then run the SharePoint configuration wizard)

• The first thing you will notice is the 3^rd option in the PowerPivot Configuration Tool (Upgrade Features, Services, Applications and Solutions) is not grayed out anymore and you will even have a nice message saying that you need to run it.

• You should Click OK on the information window and then click OK to execute the Upgrade.

   

• Click Run. Sit back, relax have a tea or coffee and wait for the update to finish

Situation 3: SharePoint 2013 with PowerPivot from SQL 2012 SP1 / SQL 2014

1. If the Analysis Services instance in SharePoint mode (PowerPivot) is installed on one or multiple servers in the farm you will do the same steps as for the Situation 2.

    

2. If you SSAS in SharePoint mode is on a server that is not a member of the SharePoint farm you will have to execute some extra steps:

    

• Install the CU for SQL 2012 SP1 / SQL 2014
• Copy the spPowerPivot.msi to your SharePoint server(s) where you have installed it before. You can find it here: C:\Program Files\Microsoft SQL Server\110 or 120\Setup Bootstrap\Update Cache\<KB number you have installed>\QFE\1033_enu_lp\x64\setup\ or you can do a Start – Run – path to CU including the name of the file and then /extract

  

   

• Install the newer version of the spPowerPivot.msi and click Yes on the warning message

   

• Finalize the installation wizard

   

   

• Run the PowerPivot Configuration Tool and upgrade the existing installation and from here is the same as Situation 2.

   

  

  Thanks to Dominique VIVES for having reviewed my post.

  Radu CARAIVAN

1. Prerequisites

In order to use CSOM within your PowerShell scripts, you first need to download the "Office Developer Tools for Visual Studio 2013". This package contains the client Dlls components for SharePoint Online. You can download the office Developer tools on this link.

You can find more details regarding the Office Developer Tools for Visual Studio in the following articles:

• Now Available: Office Developer Tools for Visual Studio 2012 https://blogs.msdn.com/b/somasegar/archive/2013/03/04/now-available-office-developer-tools-for-visual-studio-2012.aspx 

• What's New in Office Developer Tools for Visual Studio 2013 – March 2014 Update https://msdn.microsoft.com/library/dn610877.aspx

Note: the examples of this post use the office developer tools of March 2014.

In this post, I' am using a PowerShell version 4.0 provided with Windows 8.1, however the scripts should also work since PowerShell 2.0 (at least).

2. Walkthrough

a. Loading Clients Assemblies

In order to manipulate SharePoint Online objects in our PowerShell script, we first need to load the Clients DLL installed with the Office Developer tools on our local machine.

We will load two client DLLs with the two following lines:

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Client")

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Client.Runtime")

 Note: "Add-Type" cmdlet is an alternative to Loadwithpartialname. LoadWithPartialName is actually deprecated (link).

b. Create Client Context and Authenticate to SPO

Now that the client DLLs have been loaded with the previous lines, we can access the SP client objects model. However in order to manipulate SharePoint objects and run operations, we need a new client context.

To create the context, we first have to provide the site collection URL:

$weburl= 'https://tenant.sharepoint.com/sites/team'

$ctx = New-Object Microsoft.SharePoint.Client.ClientContext($webUrl)

Then we should provide the site collection administrator credentials to the context object to authenticate against on the site:

$username = 'user@tenant.onmicrosoft.com'

$password = Read-Host -Prompt "Password for $username" –AsSecureString

 $ctx.Credentials = New-Object Microsoft.SharePoint.Client.SharePointOnlineCredentials($username, $password)

 Note: if the credentials or the WebUrl are wrong, you will face an error when executing the above command.

c. Query Objects through Context

Now that we are authenticated to a SPO Site and that we have a context object, we can access objects by loading them in the current context.

The following query will retrieve the site (SPWeb) in the $ctx:

$web = $ctx.Web

$ctx.Load($web);

$ctx.ExecuteQuery();

$web.Title # will print the name of the site

Note: we could also retrieve the site collection (SPSite), $site = $ctx.Site

Now, that we have the site (SPWeb), we can also query objects like lists (SPList) and their basic properties:

$listname = "Documents"

$list = $context.Web.Lists.GetByTitle($listname);

$ctx.Load($list);

$ctx.ExecuteQuery();

$list.ItemCount # will print the number of documents and folders

With the following PowerShell script, we will upload a local Temp.txt file to a SharePoint document library.

This script is provided on an "as is" basis without warranties of any kind, whether express or implied. The entire risk as to the quality and performance of the code is with the end user.

SPO_CreateListItem.zip

Contexte

Vous avez généré sur votre environnement SharePoint 2013 une solution Visual Studio de type Visual Web Part et cette solution comporte un élément UpdatePanel (AJAX Extensions) ainsi qu’un élément InputFormTextBox (Microsoft.SharePoint.WebControls.InputFormTextBox).

Cette solution pourrait avoir la forme suivante :

L’intérêt du contrôle <asp:Button ID="btn" runat="server"  Text="Refresh Panel" OnClick="btn_Click"/> est de pouvoir déclencher un post de la page et de mettre en évidence le fonctionnement présenté dans cet article de blog.  Le code « behind » de ce contrôle pourrait effectuer l’action suivante :

Au final la page affichée par SharePoint pourrait avoir la forme suivante :

Un clic sur le bouton « Refresh Panel » aura l’effet suivant :

Le contrôle RTE ainsi que la barre d’outils sont dupliqués, le contenu est perdu et le contrôle devient non opérationnel.

Résolution

Des informations complémentaires sur ce comportement sont données dans le paragraphe « Conclusion ».

Depuis SharePoint 2013, un nouveau mode de rendu des pages ASPX est proposé, nommé « Minimal Download Strategy ».  Cette fonctionnalité accélère le rendu d’une page lorsque peu d’éléments changent sur cette page.  Dans ce contexte, les contrôles utilisés sur la page doivent pouvoir être rappelés. En d’autres termes, le code de l’élément doit être fonctionnel en mode réentrant. Dans l’exemple ci-dessus, nous voyons très bien que l’élément InputFormTextBox présente un dysfonctionnement dans un tel contexte.

Pour contourner ce fonctionnement, l'idée est de vérifier si l'élément est déjà sur la page lors de son appel pour affichage. Si tel est le cas il faut bloquer cet appel.

Voici, ci-dessous, quelques méthodes permettant de mettre en place ce contournement :

Premier exemple, dans une simple page ASPX

Dans un tel contexte, le code suivant, ajouté dans une page ASPX, serait suffisant :

Deuxième exemple, dans le cadre de notre web-part

Dans ce cas, cela se complique un peu. En effet, la fonction document.getElementById, pour pouvoir être utilisable, va nécessiter de fournir le ClientID du contrôle recherché sur la page ASPX.

Première solution

Il faut récupérer le ClientID du contrôle en éditant le code source de la page dans IE.  La contrainte ici est que si la page est modifiée, alors le ClientID va changer. Il sera nécessaire de recompiler la solution Visual Studio et la redéployer.

Le code aurait la forme suivante :

Deuxième solution

Cette solution semble plus optimale pour contourner ce comportement.  Elle consiste à remplacer la fonction JavaScript exposée ci-dessus par la version suivante :

Dernière précision

Il n’est pas nécessaire d’ajouter le code ci-dessus directement dans le fichier ASCX de la solution Visual Studio.  Ce code peut être injecté par la fonction suivante déclarée dans le fichier ASCX.CS de la solution Visual Studio.

Conclusion

Ce dysfonctionnement a été rapporté au groupe produit SharePoint.  Leur décision a été de ne pas toucher au code source utilisé par l’élément Rich Text Editor.  RTE existe depuis plusieurs versions de SharePoint et le modifier maintenant pourrait avoir des impacts inattendus sur des plateformes SharePoint déjà installées.

La solution de contournement exposée ci-dessus a été officialisé par le groupe produit SharePoint et la fourniture d’une solution sous forme de correctif est pour l’instant exclue des prochaines mises à jour SharePoint.

Je remercie Cédric Naudy pour la relecture de ce billet.

Yamine Taiëb

Les logs ULS contiennent les temps d'exécution dans les évènements B4LY. Les évènements B4LY ne sont logués que lorsque pour le produit SharePoint Foundation, la catégorie Monitoring est à High ou plus verbeuse.

J'ai écrit un script PowerShell pour extraire les temps d'exécution des logs ULS, pour un correlation ID donné. L'objectif est de comprendre rapidement ce qui a consommé le temps de réponse. J'ai publié le script à https://dumpexecutiontime.codeplex.com/  

La documentation complète (syntaxe, exemples, paramètres) est disponible sur codeplex.

Pour extraire les temps d'exécution:

1. Mettre le niveau de diagnostic pour le produit SharePoint Foundation, catégorie Monitoring à High ou supérieur.
2. Reproduire le problème
3. Enregistrer localement le script Dump-ExecutionTime.ps1 depuis https://dumpexecutiontime.codeplex.com/.
4. Dans une session PowerShell, exécuter Dump-ExecutionTime.ps1 :

dir v:*log | C:\Tests\Dump-ExecutionTime.ps1 -Threshold 500

La sortie sera par exemple:

Extracting Execution Times above 500 ms from file V:\srs\Ignacio Verbose-c52663.log with correlation

id matching *

ExecTime         Monitored Scope
----------       ------------------------------
   729.130       Leaving Monitored Scope (Directory Search).
   792.014       Leaving Monitored Scope (Directory Search).
   666.610       Leaving Monitored Scope (PortalSiteMapNode: Populating navigation children for web:

/<PII:..>).
   722.340       Leaving Monitored Scope (Directory Search).
   659.460       Leaving Monitored Scope (Directory Search).
   675.208       Leaving Monitored Scope (Directory Search).
   510.887       Leaving Monitored Scope (Directory Search).
   616.288       Leaving Monitored Scope (Directory Search).
   603.682       Leaving Monitored Scope (Directory Search).
   523.035       Leaving Monitored Scope (Directory Search).
   592.420       Leaving Monitored Scope (Directory Search).
   507.795       Leaving Monitored Scope (Directory Search).
   620.947       Leaving Monitored Scope (Directory Search).
 8,580.957       Leaving Monitored Scope (Render the Web part of the PII own documents).
 8,581.096       Leaving Monitored Scope (Redner the Web part- Main).
 8,641.322       Leaving Monitored Scope (SharePointForm Control Render).
14,294.430       Leaving Monitored Scope (Request GET:https://server.domain.com/Forms/AllItems.aspx)).

17 monitored scopes matched, for a total of 48317.62 ms

Dans cet exemple, les appels à Directory Search (surlignés en jaune) sont responsables de la plus grande partie du temps de réponse.

Je remercie Dominique Vives pour la relecture de ce billet.

Vincent Runge

Vous avez généré sur votre environnement SharePoint 2010 une solution basée sur la fonctionnalité variations.

Imaginons que cette solution est la forme simple suivante :

• Une collection de sites générée à partir du template de site « Publishing Portal ».
• Cette collection de site héberge le site racine (de référence) pour les autres labels.
• Un ou deux autres labels, voir beaucoup plus, sont présents dans cette solution basée sur les variations.

Au final la solution disponible sur SharePoint 2010 pourrait avoir la forme suivante.

Vous décidez de migrer ce contenu vers SharePoint 2013. Pour ce faire, la base de données est sauvegardée, restaurée sur le nouvel environnement SQL et attachée à la nouvelle application web SharePoint 2013 avec la commande PowerShell « Mount-SPContentDatabase ».

Dans ce nouvel environnement toute modification effectuée sur le label racine ne sera plus propagée vers les labels « enfants » faisant parties de la hiérarchie.

Résolution

La raison de ce dysfonctionnement, après la migration, est que tous les labels, autre que le label racine, devraient avoir une propriété nommée « NotificationMode » égale à False, alors que le label racive devrait cette propriété égale à True, ce qui n'est pas le cas. Cette propriété après la migration est positionnée à Null pour tous les labels.

Une solution de contournement a été trouvée par le service support de Microsoft et ce dysfonctionnement a été reportée auprès du groupe produit SharePoint.

Conclusion

La solution de contournement suivante a été officialisée (supporté) par le groupe produit SharePoint et la fourniture d'une solution sous forme de correctif est pour l'instant hors du champ de vision des prochaines mises à jour SharePoint 2013.

Le script PowerShell suivant peut être utilisé pour mettre à jour les labels appartenant à la hiérarchie.

$web = Get-SPWeb https://nomDuSite

$list = $web.GetListFromUrl("/Variation Labels/AllItems.aspx")

$nbItems = $list.ItemCount

For ($i = 0 ; $i -lt $nbItems ; $i++)

{

   If ($i -eq 0)

   {

     $item = $list.Items[$i]

     $item["NotificationMode"] = $true

     $item.Update()

   }

   Else

   {

     $item = $list.Items[$i]

     $item["NotificationMode"] = $false

     $item.Update()

   }

}

Je remercie Dominique Vives pour la relecture de ce blog.

Yamine Taiëb