Archive

Archive for the ‘PowerShell’ Category

SharePoint 2016 – Fast Site Collection

Hi Folks !

Parmi les nouveautés annoncées de SharePoint 2016, la performance de création des sites collection a été améliorée en diminuant les fonctionnalités activées par défaut. C’est un peu dans la même lignée que le Minimum Role lors de la création d’un serveur SharePoint.

Nous allons voir comment ça marche et surtout comment l’utiliser

Tout d’abord, vous ne verrez pas dans les menus SharePoint de la CA un bouton magique pour effectuer l’action… C’est en PowerShell que tout ce passe par ici les commandes !

L’activation de la fonctionnalité pour le Template de site qui doit être créé rapidement :

Juste pour rappel la liste des templates s’obtient avec la commande :

  • Get-SPWebTemplate puis vu que nous souhaitons que les Templates 2015 :
  • Get-SPWebTemplate | ?{$_.CompatibilityLevel -eq 15}
  • Enable-SPWebTemplateForSiteMaster -Template [TemplateName] -CompatibilityLevel 15
Une fois le Fast Site Collection actif, il faut créer un nouveau SiteMaster avec la commande suivante :
  • New-SPSiteMaster -ContentDatabase [DBName] -Template [TemplateName]
27-08-2015 11-41-32Vous pouvez lister les sites master avec la commande :
  • Get-SPSiteMaster
Vous verrez alors FeaturesToActivateOnCopy
Pour connaître les fonctionnalités qui seront activées lors de l’utilisation du Master passez les commandes suivantes :
(Il est possible de boucler pour récupérer tous les IDs et avoir tous les Noms, je le veux volontairement simple)
  • $var = Get-SPSiteMaster | ?{$_.SiteId -eq « SITEID »}
  • $var.FeaturesToActivateOnCopy | ft -autosize
  • Get-SPFeature -Identity « FeatureID »
Hop c’est disponible et donc passons maintenant à la création de la Site Collection avec la commande suivante :
  • New-SPSite http://URL/ -Template [Template] -ContentDatabase [DBName] -CompatibilityLevel 15 -CreateFromSiteMaster -OwnerAlias [domain\login]
 27-08-2015 11-47-09
En y regardant de plus prêt ce qui ce passe réellement est une copie de la base de données lors de l’utilisation du Fast Site Collection Creation, l’activation des fonctionnalités étant déjà faites, du coup on gagne en temps de traitement, contrairement à une création « classique » où l’activation de la fonction ce fait une fois le site créé.
Have fun & Stay Tuned !
Publicités

SharePoint 2016 IT Preview

Hi Folks,

J’espère que vous avez passé de très bonnes vacances et qu’elles ont été reposantes 🙂 car en cette reprise plein de nouvelles choses sur le collaboratif à commencer par SharePoint 2016 et sa preview 🙂

Voici quelques autres liens à garder sous le coude et à lire :

Pour celles / ceux qui ne le saurait pas encore, en termes de planning voici ce qui avait été annoncé

25-08-2015 20-17-42

En termes de rendu final une fois SharePoint installé voici ce que ça donne :

  • On retrouve l’App Launcher d’Office 365 – L’idée est justement peut être de vous faciliter par la suite l’adoption de 365 🙂

24-08-2015 22-53-46

Là on ce dit : « Ohh !! Chouette mes utilisateurs ne vont pas être complètement paumés déjà que … (vous compléterez en fonction de vos envies ici) »

Côté nouveautés je ferai un point dans un article suivant pour l’aspect utilisateurs, compliance, etc. … voir sujet par sujet pour que cela reste digeste.

Au niveau de l’installation honnêtement rien de spécial à signaler, et pour une installation en Preview ça c’est même SU-PER bien déroulée cf.: la gymnastique de la version 2013 pour récupérer les prérequis particulièrement ce qui était lié au Distributed Cache 😉

La grande news est l’écran suivant lors de l’installation qui vous permet d’ajouter des serveurs rôles par rôles (Minimun Role) c’est un gain de temps très intéressant afin d’éviter les éternels sujets « Quels services je dois démarrer ? »

Vous avez tous les détails par ici : http://sharepoint.codes/2015/08/25/sharepoint-2016-tour-du-propritaire-prsentation-des-diffrents-rles-du-serveur/

24-08-2015 22-14-59

En fonction du rôle sélectionné vous aurez donc certains services déjà activés.

Par d’inquiétude si vous souhaitez changer le rôle de votre serveur, vous avez un menu permettant de le faire « Convert server role in this farm » ou bien en PowerShell une fois récupérer le role du serveur avec Get-SPServer.

Plus proprement:

$role = Get-SPServer

$role.role= »Application »

$role.update()

Les roles possibles sont : WebFrontEnd | Application | DistributedCache | Search | SinglerServerFarm

Côté centrale d’administration, rien de fulgurant visuellement parlant quelques ajouts de fonctionnalité qui étaient attendues comme le redémarrage des services plutôt qu’en PowerShell

24-08-2015 22-51-58

Le fameux « Fix » permettant d’auto réparer le service en question – a tester; mais déjà SharePoint vous informe sur l’état du service « In Compliance »

Avait été aussi annoncé le retrait de FIM en tant que produit tier. Du coup la synchronisation avec SharePoint ne pose plus aucun problème… vous allez me dire :

  • Et si j’ai des synchronisations existantes…
Le retrait de FIM indique bien évidemment que la synchronisation ne ce fait plus de manière bi-directionnel et du coup on ne fait que de l’import nativement, si vous souhaitez quand même utiliser la synchronisation bi-directionnel (j’ai les photos de l’AD des utilisateurs dans SharePoint et ils ont le droit de la changer) il vous faudra alors installer FIM Server (https://technet.microsoft.com/en-us/library/ff512686(v=ws.10).aspx)
Bref FIM n’est pas encore mort…
Ok c’est bien tout ça … mais en quoi c’est Cloud
Effectivement cette version en Preview ne le met pas très en avant, l’hybride est bien évidemment possible, mais les fonctionnalités telles que le Search Hybrid n’est pas disponible dans cette preview.
Vous verrez assez vite dans les modèles de site collection, il y a un Compliance Center, je n’ai pas encore pu jouer avec, mais les détails viendront par la suite aussi je vous remets ce fameux slides des nouveautés attendues qui vont être à tester 🙂
25-08-2015 20-59-45
Côté PowerShell je vous joins un fichier Excel avec des slicers permettant d’explorer les différentes commandes qui arrivent avec cette version 2016
Pour les lister toutes :
  • Get-Command –PSSnapin « Microsoft.SharePoint.PowerShell »
Stay Tuned & Have fun  !

ISE Steroids for PowerShell

Hey Folks !

 

Aujourd’hui je voudrais vous parler d’un tools pour PowerShell qui me semble intéressant en quelques lignes, développé par le Dr. Tobias Weltner (MVP PowerShell); il s’agit de « ISESteroids »

ISESteroids est une extension pour ISE à partir de PowerShell 3 et version supérieure. Permettant de rendre plus simple la vie des scripteurs, factorisation, contenu des variables, versioning, etc. … Je vous invite vivement à faire un petit tour sur le site http://www.powertheshell.com/ pour avoir encore plus de détails.

Alors à quoi cela ressemble ?

ISE sans ISESteroids :

Avec ISESteroids :

 

Et quelles sont les nouvelles fonctionnalités ?

Voici quelques fonctions assez cool :

Le remote PShell facile à mettre en place

 

Avoir toujours sous le coude l’ensemble des variables :

 

Souvent lorsque nous scriptons, nous les infras, l’indentation n’est pas souvent très clair, nous ajoutons des espaces, des virgules, qui soit font échouer le script, soit ne permette pas une lecture « saine » … avec ISESteroids c’est fini. Voici un exemple de ce que ISESteroids permet de « Fixer »

 

Il vous sera alors possible de normaliser votre code très facilement :

 

Une fonction que je trouve vraiment top est la possibilité de faire du versioning de script. Effectivement la commande copier / coller fonctionne très bien à condition de faire des folders pour chaque script et conserver un file system rangé, mais sur des développements plus complexe que du simple script d’administrateur, type automate, le versionning est une très bonne chose, et notamment lors de la création de Framework PowerShell.

Une fois

 

Basé sur un système de snapshot, vous pourrez également faire des comparaisons entre les deux versions de votre script.

 

C’est une présentation assez succincte de ce que propose l’outil, personnellement je le trouve assez pratique.

N’hésitez pas à faire un tour sur le blog de Cantoris https://cantoriscomputing.wordpress.com/2014/10/25/ise-steroids-2/ pour avoir plus de détails 

 

 

Happy PowerShelling !

Catégories :PowerShell

Backup Error SharePoint 2013

Hi folks,

Un petit post rapide concernant les sauvegardes SharePoint 2013 (RTM),

Lorsque vous effectuez une sauvegarde SharePoint, il est nécessaire que vous ayez les droits adéquats (Ecriture, modification, création de folder) dans le dossier cible de sauvegarde sinon quelques erreurs peuvent apparaitre.

Problème 1 :

La première est clairement une question de droits :

FatalError: Object Search SA failed in event OnBackup. For more information, see the spbackup.log or sprestore.log file located in the backup directory.

    FaultException: Management called failed with System.InvalidOperationException: ‘Job failed: Have tried to perform backup/restore operation twice on all in-sync members in cluster SPb23a814e1ed2.0, but none succeeded.

Last failure message: Microsoft.Ceres.SearchCore.Seeding.SnapshotTransferException: Could not send chunk ms\%default\gen.0000000000000000.state: Localpath:

    [0-147> to target BackupDirectoryTarget[directory=F:\FarmBackup\spbr0000\I.0.0,validateTransfers=False]

at Microsoft.Ceres.SearchCore.Seeding.SnapshotSender.SendChunks(ISnapshot snapshot, ISeedSource source, ISeedTarget target, SeedStatus status, Func`1 checkAborted, Int32 targetFragIndex)

at Microsoft.Ceres.SearchCore.Seeding.SnapshotSender.FirstPhaseTransfer(ISeedSource source, ISeedTarget target, Action`1 updateProgress, Func`1 shouldAbort)

at Microsoft.Ceres.SearchCore.Seeding.BackupWorker.BackupWork.DoFirstPhaseWork()’ at at Microsoft.Ceres.SearchCore.IndexController.BackupService.ThrowOnFailure(JobStatus status)

at Microsoft.Ceres.SearchCore.IndexController.BackupService.ProgressFirstPhase(String handle)

at Microsoft.Ceres.SearchCore.IndexController.IndexControllerManagementAgent.WrapCall[T](Func`2 original)

Could not send chunk ms\%default\gen.0000000000000000.state

Résolution :

  1. Attribuer le full control ou la full ecriture à everyone è Rapide, mais loin d’être sécure sauf si vous appliquez la règle du (« si l’utilisateur ne sais pas qu’il a accès, il n’ira pas »)
  2. Attribuer les droits nécessaires aux comptes nécessaires

    Le service du minuteur Windows SharePoint Services Timer V4 (SPTimerV4) et le compte de service SQL Server dans SharePoint 2013 effectuent des opérations de sauvegarde et restauration au nom des utilisateurs. Ces comptes de service nécessitent des autorisations de type contrôle total sur tous les dossiers de sauvegarde.

Problème 2 :

Cette problématique a été rencontrée chez un client

Description de l’erreur : SharePoint essaie de faire un job de backup sur le service Search SA et essaie plusieurs fois, mais n’y arrive pas « Could not prepare first phase backup » alors la stack trace apparait (et me parle de composant d’administration de recherche et d’index) les erreurs suivantes sont liées à la non sauvegarde du service de recherche «Aborted due to error in another component. »

FatalError: Object Search SA failed in event OnBackup. For more information, see the spbackup.log or sprestore.log file located in the backup directory.

    FaultException: Management called failed with System.InvalidOperationException: ‘Job failed: Have tried to perform backup/restore operation twice on all in-sync members in cluster SP987sjz98768.0, but none succeeded.

Last failure message: Microsoft.Ceres.SearchCore.Seeding.SnapshotTransferException: Could not prepare first phase backup snapshot

at Microsoft.Ceres.SearchCore.Seeding.SnapshotSender.FirstPhaseTransfer(ISeedSource source, ISeedTarget target, Action`1 updateProgress, Func`1 shouldAbort)

at Microsoft.Ceres.SearchCore.Seeding.BackupWorker.BackupWork.DoFirstPhaseWork()’ at at Microsoft.Ceres.SearchCore.IndexController.BackupService.ThrowOnFailure(JobStatus status)

at Microsoft.Ceres.SearchCore.IndexController.BackupService.ProgressFirstPhase(String handle)

at Microsoft.Ceres.SearchCore.IndexController.IndexControllerManagementAgent.WrapCall[T](Func`2 original)

Debug:

Server stack trace:

at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)

at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)

at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)

at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]:

at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)

at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)

at Microsoft.Ceres.SearchCore.Admin.IIndexControllerManagementAgent.ProgressFirstPhase(String handle)

at Microsoft.Office.Server.Search.Administration.BRIndexComponent.RetryWhileNoEndPoint[T](Func`2 action, SPBackupRestoreInformation args, Guid ssaId, TimeSpan retryTimeout)

at Microsoft.Office.Server.Search.Administration.BRIndexComponent.RetryWhileNoEndPoint[T](Func`2 action, SPBackupRestoreInformation args, Guid ssaId, TimeSpan retryTimeout)

at Microsoft.Office.Server.Search.Administration.BRIndexComponent.<>c__DisplayClass13`1.<RetryWhileNoEndPoint>b__12()

at Microsoft.SharePoint.SPSecurity.<>c__DisplayClass5.<RunWithElevatedPrivileges>b__3()

at Microsoft.SharePoint.Utilities.SecurityContext.RunAsProcess(CodeToRunElevated secureCode)

at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(WaitCallback secureCode, Object param)

at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(CodeToRunElevated secureCode)

at Microsoft.Office.Server.Search.Administration.BRIndexComponent.RetryWhileNoEndPoint[T](Func`2 action, SPBackupRestoreInformation args, Guid ssaId)

at Microsoft.Office.Server.Search.Administration.BRIndexComponent.WaitPhaseComplete(SPBackupInformation args, Func`2 getProgress, Int32 sleepTime)

at Microsoft.Office.Server.Search.Administration.BRIndexComponent.WaitFirstPhaseBackupComplete(SPBackupInformation args)

at Microsoft.Office.Server.Search.Administration.TwoPhaseBackupHelper.WaitFirstPhaseBackupCompleteChildren(SPBackupInformation args)

at Microsoft.Office.Server.Search.Administration.SearchServiceApplication.OnBackup(SPBackupInformation args)

Verbose: Starting object: http.

Verbose: Starting object: https.

Verbose: Starting object: Search SA.

FatalError: Object Search SA failed in event OnBackup. For more information, see the spbackup.log or sprestore.log file located in the backup directory.

    Aborted due to error in another component.

Résolution :

  1. Vu ce que me racconte ce très chère fichier de logs, je decide d’aller faire un petit tour sur le moteur de recherché via la Centrale d’Administration.
  2. Quand tout fonctionne bien, tout est vert

    Les warning sont en jaune,

    Les erreurs sont en rouge,

    Jusque-là je pense que comme n’importe qui, si vous apercevez la moindre icône non verte, alors le stress vous envahi… mais pas de panique

    Dans le cas de figure ci-dessus, le service de recherche ne se sauvegardai pas car il était en warning sur les Index, ce qui semble logique vu ce que nous avons trouvé dans les logs.

    Pour résoudre cette petite problématique :

    1. Détruire le service et le reconstruire è Rapide, Net, Pas besoin de se poser trop de question c’est bon si vous n’êtes pas en prod là
    2. Construire un nouvel index avec PowerShell : http://technet.microsoft.com/en-us/library/jj862355.aspx#Search_Index_Part

Par contre il faut noter qu’il y a pas mal de problème concernant la manipulation du service de recherche de SharePoint 2013 en version RTM et que quasiment toutes les modifications (Index, Crawler, etc. …) ce solde généralement par la recréation du service de recherche en entier.

La mise à jour de SharePoint 2013 avec les derniers Cumulatif Update du mois d’Aout http://technet.microsoft.com/en-us/sharepoint/jj891062.aspx permettent de manipuler de manière plus sereine le moteur de recherche.

Je n’ai pas encore testé le CU d’Aout avec le moteur de recherche, mais je pense que le plus propre dans l’ordre serai soit :

  1. Delete Search SA > MAJ > New Search SA
  2. Backup > Delete Search SA > MAJ > Restore Search SA
  3. Backup > MAJ > Restore
  4. MAJ

A voir ce que le prochain Service Pack de SharePoint 2013 apportera.

Enjoy & Have Fun !

Work Management Application

10 septembre 2013 1 commentaire

Hey !

De plus en plus de clients mettent en place le Work Management Service Application (WMA) mais souvent les tâches agrégées posent problème…

Aussi je vous propose de voir un peu plus en détails de quoi il s’agit, et vous donner quelques « trucs » que l’on appelle aussi des Best Practice.

C’est quoi le « Tâches » / « Tasks » sur mon profil SharePoint ?

 

Dans SharePoint, la liste des tâches agrège et vous montre toutes les tâches qui sont assigné à l’utilisateur connecté (tâches de Workflow, Liste, …)

C’est dispo dans SharePoint Online également.

 

A quoi ça sert ?

Dans les versions précédentes de SharePoint, l’utilisateur devait se connecter à l’ensemble des systèmes (Exchange, Project, …) pour connaitre ses tâches affectées. Il n’y avait aucune coordination et les alertes provenaient de tous les systèmes

Schématiquement nous avions ceci :

 

Maintenant l’ensemble est stocké à un seul endroitJ, l’utilisateur ce connecte à son site, et visionne les tâches à effectuer en un point central, schématiquement nous avons :

 

C’est quoi l’avantage ?

  • Avoir l’ensemble de ces tâches à un seul et unique endroit,
  • Avoir une timeline dynamique agrégeant l’ensemble des tâches,
  • Synchronisation avec Outlook (Uniquement avec Exchange 2013)

    http://technet.microsoft.com/en-us/library/jj554516.aspx

  • Catégorisation des tâches,
  • Possibilité de marquer les tâches importantes,
  • Rechercher parmis les tâches,

Ca fonctionne comment ?

Comme tout dans SharePoint via à Service, le WMA (Work Management Application)

Ce nouveau service fourni avec SharePoint 2013 offre les fonctionnalités suivantes à un seul endroit du portail :

  • Donne la possibilité à l’utilisateur de visionner et suivre ses actions (todo list)
  • Agrégation des tâches outlook, project et sharepoint (Merci Exchange 2013)
  • Basé sur un fournisseur afin de connecter d’autres systèmes

Pour que tout se passe bien il faut :

  1. Pour l’agrégation de tâches SharePoint et Project dans le Newsfeed :
    1. WMA
    2. User Profile Service Application
    3. My Site SharePoint
    4. Search Service Application

       

  2. Pour l’agrégation des tâches exchange il faut tout le 1. Plus :
    1. Exchange 2013

Comment ca se configure ?

  1. Création et paramétrage d’un SSA (Search Service App)
  2. Création et paramétrage du MySite Host
  3. Création et configuration de l’UPSA (User Profile Service App)
  4. Création du Work Management Service App (WMA)
  5. Création d’un sites SharePoint ou Project
  6. Assigner des tâches
  7. Faire un Crawl !

Attention si vous avez un project serveur associé à SharePoint 2013, considérer les points suivants :

  1. Créer WMA dans un Application Pool trusté par Project Server c’est plus simple pour provisionner les sites PWA APRES que le WMA soit créé.
  2. Si le PWA existe déjà, vous devrez donner les droits manuellement au compte WMA sur la base de données de Project Server (PSDataAccess role)

Le souci courant

SharePoint ne rafraichi pas les tâches… et reste en 1901…

Problème 1

Symptômes

Solution

Donner les droits au compte qui est en Full Control sur le WMA, le full control sur l’UPSA

Voici la configuration de l’UPSA

 

Et celle du WMA

 

Problème 2

Symptômes

L’agrégation ne fonctionne pas

Essayer sur un nouveau site, nouvelle liste, nouvel utilisateur.

Les tâches sont assignées mais rien n’apparait dans les tâches du MySite

Même si vous attendez plusieurs heures

 

Solution

Le processus n’est pas réellement documenté mais il peut s’agir d’un contrôle temporel, donc lié à la recherche, plus précisément au Crawl

Vérifier que l’utilisateur à bien un MySite, que ces tâches sont rafraichies, et surtout d’un crawl ai eu lieu

Vérifier que la recherche fonctionne,

Vérifié également que l’utilisateur à bien accès aux tâches de la liste, s’il n’a pas la permission de les voir, rien ne s’affichera…

Vérifier le Crawl Continu pour les sites SharePoint, et gérer les intervalles de temps du Crawl Continu :

$ssa= get-spenterprisesearchserviceapplication

$ssa.SetProperty(« ContinuousCrawlInterval »,x)

X étant le nombre de minutes entre chaque intervalle (par default il est de 15min), le plus court est de 1minute.

A Savoir

L’agrégation multi ferme du WMA n’est pas supportée même si la ferme est dans le même domaine.

La configuration ne s’effectue qu’en PShell

Pas d’option dans la CA

Set-SPWorkManagementServiceApplication

Les paramètres les plus importants sont en Jaune et Rouge

Paramètre

Obligatoire

Description

Identity

Obligatoire

Spécifie l’application de service à mettre à jour.

Le type doit correspondre à un GUID valide au format 12345678-90ab-cdef-1234-567890bcdefgh, un nom d’application de service de paramètres d’abonnement valide (par exemple SubSettingsApp1), ou une instance d’un objet SPWorkManagementServiceApplication valide

ApplicationPool

Facultatif

Spécifie le nom d’un pool d’applications à utiliser ; par exemple, SharePoint – 1213. Si aucune valeur n’est spécifiée, le pool d’applications par défaut est utilisé.

AssignmentCollection

Facultatif

Gère les objets de manière à optimiser leur libération. L’utilisation d’objets, tels que SPWeb ou SPSite, peut consommer des quantités de mémoire élevées et le recours à ces objets dans des scripts Windows PowerShell implique une gestion appropriée de la mémoire. À l’aide de l’objet SPAssignment, vous pouvez affecter des objets à une variable et les libérer dès qu’ils ne sont plus nécessaires afin de libérer de la mémoire. Lorsque les objets SPWeb, SPSite ou SPSiteAdministration sont utilisés, ils sont automatiquement libérés si une collection d’attributions ou le paramètre Global ne sont pas utilisés.

Remarque :

Lorsque le paramètre Global est utilisé, tous les objets sont contenus dans le magasin global. Si des objets ne sont pas utilisés immédiatement ou libérés à l’aide de la commande Stop-SPAssignment, un scénario d’insuffisance de mémoire peut se produire.

Confirm

Facultatif

Vous demande confirmation avant d’exécuter la commande. Pour plus d’informations, tapez la commande suivante : get-help about_commonparameters

MinimumTimeBetweenEwsSyncSubscriptionSearches

Facultatif

Spécifie le délai minimal (en minutes) pour trouver de nouveaux clients qui veulent synchroniser des tâches liées aux services web Exchange. Chaque client doit être trouvé une seule fois à l’aide de cette routine. Les utilisateurs de ce client seront inclus lors de la prochaine synchronisation de client.

MinimumTimeBetweenProviderRefreshes

Facultatif

Spécifie le délai minimal (en minutes) entre les actualisations d’un fournisseur pour un utilisateur donné. Il ne peut pas y avoir d’actualisation des données si la valeur n’est pas atteinte et si toutes les opérations d’actualisation contiennent une valeur Null avant une actualisation. La valeur par défaut est 5 minutes.

MinimumTimeBetweenSearchQueries

Facultatif

Spécifie le délai minimal (en heures) entre les demandes de recherche pour un utilisateur donné. Ce paramètre sert à découvrir les nouveaux fournisseurs inconnus afin de leur affecter des tâches pour cet utilisateur. La valeur par défaut est 3 heures.

Name

Facultatif

Spécifie le nom de l’application de service Gestion du travail.

NumberOfSubscriptionSyncsPerEwsSyncRun

Facultatif

Spécifie le délai minimal (en minutes) entre les recherches d’un nouveau client pour la synchronisation des tâches liées aux services web Exchange. Chaque client doit être trouvé une seule fois à l’aide de cette méthode. La valeur par défaut est 30 minutes.

NumberOfUsersEwsSyncWillProcessAtOnce

Facultatif

Spécifie le nombre maximal d’utilisateurs qu’un ordinateur d’une instance de service doit synchroniser à l’aide des services web Exchange en une seule fois parmi tous les clients. Ceci a une influence directe sur la charge de l’ordinateur. Chaque synchronisation dure 45 secondes (constante). La valeur par défaut est 10.

NumberOfUsersPerEwsSyncBatch

Facultatif

Spécifie le nombre maximal d’utilisateurs qu’une instance de service tentera de synchroniser sur un client donné à l’aide des services web Exchange en fonction de l’intervalle du travail du minuteur. La valeur par défaut est 100.

WhatIf

Facultatif

Affiche un message qui explique l’effet de la commande au lieu de l’exécuter. Pour plus d’informations, tapez la commande suivante : get-help about_commonparameters

 

Concernant l’agrégation des tâches exchange, elles tournent via un Job SharePoint configuré pour fonctionner toutes les minutes.

C’est SharePoint qui appel Exchange, plus simple en terme de configuration, et nécessité uniquement un seul trust.

Par défaut la fonction de ferme est activée

Une fois configurer les utilisateurs peuvent alors utiliser la nouvelle action du ruban :

 

Recommandations

Si Exchange 2013 ne fait pas parti de votre SI, alors il est recommandé de désactiver la fonction d’agrégation de la ferme SharePoint afin de ne pas perturber plus l’utilisateur.

Le bouton Sync to Outlook n’apparaitra pas, et le bouton Connect to Outlook le remplacera.

Pour plus de détail je vous invite a lire le White Paper suivant : https://www.microsoft.com/en-us/download/details.aspx?id=38799

« My Tasks Aggregation in SharePoint Server and ExchangeTask Integration« 

Automatiser l’installation du WAC Server

14 août 2013 5 commentaires

Hi folks,

Aujourd’hui un court post sur l’automatisation de l’installation des WAC de SharePoint 2013.

Sur codeplex vous trouverez l’installeur autospinstall permettant d’automatiser une bonne partie de l’installation d’une ferme SharePoint. Mais la fonctionnalité d’installation des OWA (Nouvellement appellée WAC) est dépréciée de l’installeur, une mise à jour future peut-être ? 🙂

Entrons dans le vif du sujet en xy étapes :

1. Ajouter les lignes suivantes dans un script en PS (ce sont les prérequis d’installation) (Prepare.ps1)

Import-Module ServerManager
Add-WindowsFeature Web-Server,Web-Mgmt-Tools,Web-Mgmt-Console,Web-WebServer,Web-Common-Http,Web-Default-Doc,Web-Static-Content,Web-Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Security,Web-Filtering,Web-Windows-Auth,Web-App-Dev,Web-Net-Ext45,Web-Asp-Net45,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Includes,InkandHandwritingServices, NET-Framework-Features, NET-Framework-Core -verbose

2. Ajouter les lignes suivantes dans un autre PS (Ce sont les commandes d’installation) (InstallWAC.ps1)

.wacserver\setup.exe /config \wac\wacserver\files\setup\config.xml

start-sleep 10
.\Update\wacserver2013-kb2810007-fullfile-x64-glb.exe /passive

start-sleep 10
.French\setup.exe /config \wac\French\files\setup\config.xml

3. Placer les fichiers suivant :

L’extraction des fichiers de l’iso du WACServer dans un dossier nommé: WAC\WACSERVER

https://www.microsoft.com/fr-fr/download/details.aspx?id=35489

L’extraction des fichiers de l’iso du WACServer en Français dans un dossier nommé: WAC\French (pour le LP French)

https://www.microsoft.com/fr-fr/download/details.aspx?id=35490

Dans le dossier Update, vous pouvez également placer les mises à jour du WAC si vous souhaitez faire la mise à jour en même temps.

4. Modification des fichiers config.xml

a. Dans le folder wacserver\files\setup\ modifier le fichier config.xml afin qu’il soit comme cela:

Pour le server de WAC: (Le serveur ne rebootera pas)

never

b. Dans le folder french\files\setup\ modifier le fichier config.xml afin qu’il soit comme cela:

Pour le serveur de WAC en Français: (Le serveur va rebooter)

autoalways

5. Exécution des scripts dans l’ordre suivant:

  • Prepare.ps1
  • InstallWAC.ps1

Vous trouverez l’ensemble de la configuration nécessaire ici : https://mickey75019.wordpress.com/2012/08/27/installation-des-offices-web-applications-sharepoint-2013/ et là https://mickey75019.wordpress.com/2013/04/29/mettre-a-jour-les-office-web-apps/ pour ajouter les pdf en reader a l’apps Word.

Enjoy & Have fun !

SharePoint & SIDHistory

24 juin 2013 1 commentaire

Hey folks,

Récemment un client m’appel suite à une migration d’AD d’une forêt A vers une forêt B, jusque-là tout va bien, sauf pour SharePoint où des problématiques d’habilitations sont apparues.

Ces problématiques sont liées au SID History et la manière dont Windows effectue et met en cache ces requêtes Name to SID et SID to Name (qui sont en fait des lookup de l’AD).

Ce cache fait penser à SharePoint qu’un utilisateur qui souhaite se connecter provient du mauvais domaine, et SharePoint essaye de créer une nouvelle identité pour cet utilisateur.

La plupart du temps il s’agit d’un problème de people picker (configurable avec les commandes STSADM ou bien PowerShell) vous trouverez la description de ce problème ici :

http://blogs.technet.com/b/rgullick/archive/2010/05/15/sharepoint-people-picker.aspx

La solution de contournement envisagez pour résoudre cette problématique est la suivante:

Fasten your seatbelt !

Le LsaCache stocke les noms d’utilisateur déjà recherché ainsi que leur domaine et leur SID. En interrogeant un DC qui a des utilisateurs qui ont à la fois le nouveau SID et le SID migré en même temps, le DC relie toujours le SID migré vers le nouveau nom d’utilisateur, et non l’ancien nom d’utilisateur. Si nous pouvons artificiellement mapper le LsaCache avec correspondances des anciens noms d’utilisateur avec leur ancien SID, nous pouvons agir comme si aucune ressource n’a encore migré.

Voici le scénario où les utilisateurs ont été migrés avec le SID-History à partir de CHILD.domainA.com à domainB.com


  1. CHILD\Michael s’authentifie sur une machine du domaine CHILD et ouvre un site SharePoint dans le DOMAINB (intranet.domainB.com)
  2. SharePoint appel IIS, qui demande à Windows un DC local pour résoudre un SID: S-1-5-21-[SID_de_CHILD]-1010
  3. Le DC local trouve le SID assigné à l’utilisateur migré dans le catalog global
  4. Le DC local retourne le nom du compte de l’utilisateur migré, DOMAIN\Michael
  5. Le serveur SharePoint ajoute le résultat à son LsaCache comme un mapping de ce SID avec le compte de DOMAIN

Ainsi, nous pouvons voir sur la photo ci-dessus que le LsaCache (la table dans le coin inférieur droit) à appliquer pour le nouveau nom d’utilisateur l’ancien ancien SID mais nous cherchons à avoir l’ancien nom d’utilisateur avec l’ancien SID

Donc, nous allons effectuer un WarmUp du LsaCache de façon à avoir :

  1. SharePoint exécute en permanence un script permettant de requêter le nom CHILD\Michael
  2. Le DC local requête le Global Catalog et ne trouve aucun enregistrement pour ce nom d’utilisateur
  3. Le DC local doit faire sa propre requête LSA pour interroger le DC du domaine CHILD pour ce nom d’utilisateur
  4. Le DC distant du domaine CHILD trouve le nom d’utilisateur et réponds avec le SID: S-1-5-21-[SID_de_CHILD]-1010
  5. Le DC de CHILD retourne la réponse au DC du DOMAINB (le DC du DOMAINB cache le résultat dans son propre LsaCache)
  6. Le DC local retourne le résultat au serveur SharePoint
  7. Le serveur SharePoint ajoute cette nouvelle entrée à son LsaCache

Donc maintenant nous avons:

Notre cache qui interroge de la manière souhaité et nous avons l’ancien nom d’utilisateur = ancien SID. De cette façon, quand une requête est faite pour OLD SID, le résultat viendra du cache avec l’ancien nom d’utilisateur.



 

  1. CHILD\Michael s’authentifie sur une machine de CHILD et ouvre un site SharePoint présent dans le DOMAINB (intranet.domainB.com)
  2. SharePoint ne demande pas au DC local le SID, il utilise le LsaCache
  3. Le LsaCache de SharePoint réponds en retour avec le username qui est relié au SID: S-1-5-21-[SID_de_CHILD]-1010 est CHILD\Michael

L’étape importante (le X rouge) où il n’y a pas d’étape J . C’est-à-dire que le serveur SharePoint n’a jamais parlé au DC pour obtenir l’ancien SID et renvoyer un résultat, ce qui signifie que nous nous sommes appuyés sur le cache de SharePoint seul.

Cette requête repose sur le LsaCache du serveur SharePoint qui possède toujours l’entrée pour le SID du domaine CHILD correspondant au nom d’utilisateur CHILD, et jamais le nom d’utilisateur correspondant du DOMAINB .

La seule façon d’y parvenir est:

  1. Une requête constante du serveur SharePoint pour le nom CHILD\username pour chaque utilisateur dans DOMAINB qui a été migré de CHILD et qui a son SIDHistory migré avec.

    Vous pouvez utiliser un outil qui invoque LookupAccountName () pour localiser le SID pour le nom d’utilisateur: CHILD\username.

    LookupAccountName est expliquée ici: http://msdn.microsoft.com/en-us/library/aa379159(v=VS.85) .

    Je pense que PsGetSid de Sysinternals serait en mesure d’aider ici aussi.

  2. En PowerShell pour connaitre le domain\username ou le sid en fonction de l’un ou de l’autre, vous pouvez utiliser le code suivant :
    Write-Host -ForegroundColor Green « 1. Domain User to SID »

    Write-Host -ForegroundColor Green « 2. SID to Domain User »

    Write-Host -ForegroundColor Green « Other to exit »

    $choice = Read-Host « Select 1 – 2 – Other »

    Switch ($choice)

    {

    1{

    write-host -foreground Green « # DOMAIN USER TO SID »

    write-host -foreground Green « # This will give you a Domain User’s SID »

    $domain = read-host « Domain »

    $user = read-host « User »

    $objUser = New-Object System.Security.Principal.NTAccount($domain, $user)

    $strSID = $objUser.Translate([System.Security.Principal.SecurityIdentifier])

    Write-host -foreground Magenta $strSID.Value

    break;

    }

    2{

    write-host -foreground Green « # SID TO DOMAIN USER »

    write-host -foreground Green « # This will allow you to enter a SID and find the Domain User »

    $SID = read-host « SID »

    $objSID = New-Object System.Security.Principal.SecurityIdentifier ($SID)

    $objUser = $objSID.Translate( [System.Security.Principal.NTAccount])

    $reponse = $objUser.Value

    Write-host -foreground Magenta $reponse

    break;

    }

    }

  3. Le LsaCache de SharePoint doit être assez grand pour être certain que les entrées qui sont requêtées ne soient jamais remplacées par les entrées du DOMAINB .

    Réglez la clé de registre HKLM\System\CurrentControlSet\contôle\Lsa\LsaLookupCacheMaxSize = (DWORD) = 0x2000 (8192 décimal)

    Si cette valeur n’existe pas, le système utilise une taille de cache par défaut de 128 entrées, ce qui est écrasée trop rapidement sur ​​les serveurs SharePoint. 8192 entrées sur une paire de serveurs équilibrés en charge devraient être en mesure de tenir toutes les SID pour tous les utilisateurs accédant au site SharePoint depuis les 2 forêts (si votre forêt a plus d’utilisateurs, vous aurez besoin d’augmenter cette valeur.

  4. Il s’agit d’une solution de contournement.

    La véritable solution serait d’avoir des utilisateurs migrés à partir CHILD.domaine.com à DOMAINB .com avec leur SIDHistory.

    Après la migration, leurs comptes CHILD doivent être désactivés ou supprimés et SIDHistory devraient être retirés des comptes DOMAINB . Il s’agit d’une action très complexe à faire, car il ne permet pas d’effectuer de test de manière simple, et le retour arrière est également extrêmement complexe.

Pour afficher les actions telles qu’elles sont effectuées par les Lookups du LSA, ajouter ces 2 DWORDs au Registre sous HKLM\System\CurrentControlSet\Control\Lsa\ :

  • LspDbgTraceOptions = 0x1 (1 signifie « enregistrer un fichier », le fichier est C:\Windows\Debug\Lsp.log)
  • LspDbgInfoLevel = 0x88888888
    (les 8 de en hexadécimal signifie « Loguer en mode verbaux autant que possible »)

Les clés de registres sont expliquées ici :

http://technet.microsoft.com/en-us/library/ff428139(v=ws.10).aspx

Donc, dans l’ensemble cela reste assez compliqué, la solution de contournement est d’augmenter la valeur pour LsaLookupCacheMaxSize et de faire fonctionner en permanence un script sur ​​le serveur SharePoint pour interroger le SID des noms d’utilisateur dans CHILD (avec un filtre pour cibler uniquement les utilisateurs qui ont été migrés vers DOMAINB).

Ceci est couvert par le CU d’Aout 2012.

Le groupe produit a ajouté une ligne de commande :

stsadm.exe -o setproperty -propertyname « HideInactiveProfiles » -propertyvalue « true »

Cela bypass les comptes désactiver et effectue une requête sur le domaine actif. L’état non supporté par Microsoft est de posséder des SID Dupliqués mais SharePoint a maintenant un peu plus de flexibilité pour travailler dans ces cas de figure.

Il existe des outils tiers permettant de ne pas avoir ce type de problème, comme AvePoint par exemple J

Quelques infos à propos de la commande STSADM –o migrateuser :

http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=75

http://technet.microsoft.com/en-us/library/cc262141.aspx

A partir du SP3 de SharePoint 2007, la notion des SID History est apparemment gérée, donc le passage du simple Service Pack de SharePoint pourrait résoudre votre problématique. Puis maintenir ces plateformes à jour est un des best practice qu’il est important de respecter (à condition évidemment de tester techniquement et recetter fonctionnellement votre solutionJ), d’autre part, le SP2 de SharePoint 2007 ne sera bientôt plus supporté par Microsoft.

A special thanks to Craig Foster (http://blogs.technet.com/b/craigf) ping back AD & SID

Enjoy & Have fun !