SharePoint à l'intérieur Gestion de projets d'entreprise avec SharePoint

Pav Cherny

Contenu

Projet Server architecture
Intégration à SharePoint
Déploiements de batterie de serveur
Bienvenue sur IIS 7
Autorisations de base de données de session
Autorisations de services partagés
Le pare-feu Windows
MOPS services et comptes de service
Intégration des services d'analyse
Conclusion

Les technologies SharePoint sont réunies pour vous ? Dans les efforts de trouver la réponse, vous avez probablement sifted dans une liste de catégories, apparemment illimitée notamment collaboration informatique social, portails, recherche de contenu d'entreprise, Enterprise Content Management, des processus métier et les formulaires, Business Intelligence et capacités de plate-forme développeur et comparé les fonctionnalités disponibles dans Windows SharePoint Services (WSS) 3.0, Microsoft Office recherche Server 2008 Express, Microsoft Office Forms Server 2007 et Microsoft Office SharePoint Server (MOSS) 2007. Toutefois, il y a une technologie considérée vous pouvez ne jamais avoir comme car Microsoft ne pas répertorie sous produits et technologies SharePoint, Enterprise Project Management (EPM), qui est activé dans Microsoft Office Project Server (MOPS) 2007.

Mais MOPS 2007 est technologie SharePoint ; il s'appuie sur et étend WSS 3.0 d'une façon qui est comparable à MOSS 2007. MOPS 2007 est le bon choix si vous souhaitez augmenter l'efficacité de collaboration en équipe dans et entre les départements via travail, ressources et Gestion des budgets au-delà les capacités de gestion des tâches léger inclus dans WSS 3.0 et MOSS 2007. Avec MOPS, vous pouvez activer les sites d'équipe dans les espaces de travail de projet, gérer la collaboration en équipe dans et entre les départements et établir une base EPM solide d'une organisation entière. Tout d'abord, toutefois, vous devez maîtriser les difficultés du déploiement.

Dans cette chronique, j'explique le déploiement de MOPS 2007 dans un environnement Windows Server 2008 avec SQL Server 2005 SP2 et WSS 3.0 SP1. Tout d'abord, J'AI examinez brièvement l'architecture MOPS pour afficher comment les composants interagissent avec WSS 3.0 un architecte système point de vue. Ces informations facilite suivre la discussion suivante de déploiement typique et défis d'intégration que vous pouvez rencontrer, comme problèmes de configuration pool d'applications manquant autorisations d'accès, erreurs de démarrage système de file d'attente et problèmes liés à SQL Server 2005 Analysis Services.

Pour illustrer le déploiement et de procédures de dépannage, j'utilise un environnement de test base avec les deux serveurs WSS 3.0 dans une batterie de serveurs, un contrôleur de domaine dédiés, et un ordinateur distinct exécutant SQL Server, similaire à l'environnement de test j'ai utilisé jusqu'ici pour cette colonne SharePoint. Vous trouverez des feuilles de calcul correspondantes des instructions étape par étape dans le support Compagnon pour cette colonne située sur le site Web TechNet Magazine.

Projet Server architecture

MOPS 2007 est un des applications SharePoint plus avancées et complexes. Il tire pleinement parti de la plate-forme WSS 3.0 pour une administration centralisée, la mise en service du site, l'authentification et sécurité. En outre, il ajoute autres composants tels que 25 généraux et spécialisés MOPS WebParts et une nouvelle collection de jusqu'à quatre bases de données MOPS par site Project Web Access (PWA). Chacun est accessible via un ensemble de 21 publics et internes MOPS services Web qui collabore forment l'interface de Project Server (PSI), comme illustré dans la figure 1 . Vous trouverez plus d'informations sur MOPS Web services sur MSDN.

La figure 1 Intégration de SharePoint avec MOPS 2007 (cliquez sur l'image pour l'agrandir)

L'architecture MOPS 2007 repose sur une variété de composants réparti entre les stations de travail client, les serveurs d'applications et les serveurs de base de données. J'aborder le plus important de ces composants dans cette colonne, mais si vous êtes intéressé par tous les détails techniques, consultez le " Projet Server architecture« documentation dans le Kit de développement Project 2007.

Gardez simplement en tête lorsque le Kit de développement logiciel (SDK) de lecture que WebPart PWA et Microsoft Office Project Professional 2007 ne pas accèdent les services Web PSI directement. Le kit de développement logiciel (SDK) suggère que clients effectuer des appels directs vers la PSI, mais la plupart des applications en fait utiliser le transfert PSI, qui est un composant dans des sites PWA qui donne accès indirect vers les services Web PSI. Uniquement les composants de serveur, tels que le service de file d'attente et le service des événements, qui s'exécutent avec autorisations system-level Vérifiez les appels PSI directs. Ce petit détail est important pour vous à retenir de résolution des situations pour plusieurs raisons, en particulier :

• Sites PWA définissent contexte de base de données (chaque site PWA unique a distinctes bases de données brouillon, publié, Archive et de création de rapports) et les autorisations utilisateur, mais les comptes d'utilisateur standard ne disposent pas accès aux services Web PSI.
• Le redirecteur PSI ne prend pas en charge l'emprunt d'identité et utilise compte du pool d'applications le site PWA pour accéder aux services Web PSI des utilisateurs.
• Appels PSI n'utilisez pas nécessairement les services Web PSI si la batterie de serveurs contient plusieurs instances de serveur à l'application.

Intégration à SharePoint

Maintenant nous allons examiner un plus près l'intégration MOPS réelle avec SharePoint. Point de vue un administrateur SharePoint, MOPS est une application Web partagée gérée comme un service de batterie de serveurs dans l'administration centrale de SharePoint 3.0. Il est relativement simple pour les administrateurs familiarisés avec les services fournisseurs partagés (SSP) dans MOSS 2007.

Mais si vous êtes un administrateur de WSS 3.0 et nouvelle à l'administration du fournisseur de services partagés, allez extraire de la feuille « déploiement Project Server 2007 », disponible dans le matériel associé, à pour obtenir des instructions détaillées créer et configurer une batterie SharePoint services partagés et PWA sites. Après l'installation MOPS et la configuration, vous pouvez analyser l'implémentation du système dans le Gestionnaire des services Internet. Comme illustré à la figure 2 , vous devriez voir distincts Web sites for services partagés, l'administration du fournisseur de services partagés et collections de sites sur un serveur d'applications MOPS.

La figure 2 Project Server 2007 l'accès via PWA et transfert PSI (cliquez sur l'image pour l'agrandir)

Clients accéder les services Web PSI via le répertoire virtuel _VTI_BIN/PSI dans un site PWA. Toutefois, les services Web PSI n'est pas résider dans ce répertoire virtuel. Le répertoire virtuel _VTI_BIN/PSI mappe sur le chemin d'accès physique suivant: % COMMONPROGRAMFILES %\Microsoft Shared\Web Server Extensions\12\ISAPI\PSI. Vous constaterez que ce répertoire contient un fichier web.config qui spécifie dans une section <http­Handlers> que toutes les demandes HTTP vers des fichiers *.asmx (c'est-à-dire, ASP.NET Web services) doivent être transmises vers un gestionnaire HTTP personnalisé, instancié via Micro­soft.Office.Project.Server.PSIForwarder­HandlerFactory.

Ce gestionnaire HTTP personnalisé est le transfert PSI. Le redirecteur PSI établit une nouvelle connexion HTTP aux services Web PSI réelles, transmet la demande du client HTTP et puis renvoie les résultats au client.

Les services Web PSI sont disponibles pour le transfert PSI via HTTP dans le répertoire virtuel PSI de l'application Web des services partagés, qui est hébergé dans le site de services Web de serveur Office. Ce répertoire virtuel correspond par défaut pour le %\Microsoft de ProgramFiles% chemin d'accès physique % Servers\12.0\WebServices\Shared\PSI Office, et c'est des où vous trouver MOPS 2007 *.asmx.

JE vous explique plus sur le site plus tard d'Office Server Web services ; pour l'instant, fait plus important pour tirer de La figure 2 est que le redirecteur PSI communique avec les services Web PSI à l'aide l'identité du compte du pool d'applications Web le site PWA au lieu de l'utilisateur actuellement connectés au site PWA.

Déploiements de batterie de serveur

Le redirecteur PSI joue également un rôle important dans déploiements batterie de serveurs qui utilisent des serveurs frontaux Web distincts et des serveurs d'applications pour augmenter l'évolutivité de système et la disponibilité. Un serveur frontal MOPS est un serveur de WSS 3.0 n'ordinateur hôte les services PSI Web ou d'autres services MOPS such as service de file d'attente et des événements service) mais fournit des clients d'accéder à des sites PWA, qui comprennent la PSI Forwarder, comme illustré dans Figure 3 .

La figure 3, une taille moyenne MOPS 2007 batterie (cliquez sur l'image pour l'agrandir)

Un serveur d'applications, d'autres part, est un serveur de WSS 3.0 qui possède l'ensemble des composants MOPS et services installés. Serveurs d'applications peuvent ordinateur hôte PWA sites, mais plus souvent que pas qu'ils uniquement fournir des services back-end aux serveurs frontaux et n'exécutez pas le service Application Web WSS. Vous sélectionner le rôle serveur lors de l'installation MOPS.

La figure 3 illustre la configuration d'une batterie de serveurs moyenne taille. Vous pouvez ajouter des serveurs frontaux supplémentaires pour augmenter l'évolutivité ainsi que les serveurs d'applications supplémentaires pour une haute disponibilité, selon les exigences de votre organisation. Il n'est pas nécessaire de configurer un cluster d'équilibrage de charge pour les serveurs d'application MOPS car le transfert PSI automatiquement charge soldes PSI demandes si plusieurs serveurs d'applications MOPS existent dans la batterie de serveurs. Pour plus d'informations concernant les options de déploiement MOPS, consultez le " Guide de déploiement de Office Project Server 2007."

Bienvenue sur IIS 7

Assez de théorie ! Nous allons résoudre certains problèmes réels qui vous pourriez être confronté pendant le déploiement de MOPS 2007. Un des mes problèmes favoris liée aux collections de sites nommée d'hôtes de sites PWA. Dans ce scénario, vous correctement déployer MOPS, configurer le fournisseur SSP, la mise en service un site PWA en mode en-tête hôte en entrant l'URL de PWA complète (par exemple, pwa) après avoir sélectionné le chemin d'utiliser Project Web Access sous ordinateur hôte de case à cocher en-tête dans la page Créer un site Project Web Access. Ensuite, après que toutes les ressources sont correctement mis en service, vous tentez d'ouvrir le site, mais, au lieu de PWA, vous atteignez l'écran d'accueil de 7 IIS standard.

C'est ce que qui se produit si le site Web par défaut n'est pas étendu de SharePoint et qu'aucun autre site Web avec une liaison de site approprié pour l'URL PWA. Sans une liaison de sites explicites, IIS associe la demande pwa avec le non étendues site Web par défaut, vous voyez l'écran d'accueil. Vous avez prévu l'administration centrale de SharePoint 3.0 pour ajouter la liaison nécessaire à l'application Web SharePoint qui vous avez sélectionné au site ordinateur hôte le PWA, mais ceci ne se produit pas.

Pour résoudre ce problème, vous devez SharePoint-étendre le site Web par défaut, puis utiliser cette collection de sites à mise en service PWA sites, comme indiqué dans la feuille Compagnon IIS de résolution des problèmes et PWA. Sinon, vous pouvez ajouter la liaison de site manquante manuellement dans le Gestionnaire des services Internet à l'application Web sélectionnée pour PWA. N'oubliez pas d'effectuer cette étape sur tous les serveurs WSS ce site ordinateur hôte le PWA.

Autorisations de base de données de session

Si vous décidez d'étendre le site Web par défaut, vérifiez que vous utilisez un compte de domaine pour le pool d'applications, voir la rubrique " Planification de comptes d'administration et de service (Office SharePoint Server)», dans le cas contraire, vous rencontrerez problèmes d'autorisation-liés après la mise en service des sites PWA généralement manifeste eux-mêmes dans un message d'erreur généralement uninformative SharePoint, comme l'affiche dans La figure 4 .

La figure 4 erreur accéder à la base de données du fournisseur de services partagés (cliquez sur l'image pour l'agrandir)

Pour obtenir des informations plus explicite, vous devez extraire les journaux de suivi que se trouve dans le répertoire % COMMONPROGRAMFILES %\­Microsoft Shared\Web Server Exten­sions­\12\LOGS. Ceci peut être une tâche fastidieuse si votre batterie de serveurs comprend plusieurs serveurs frontaux Web de la à charge équilibrée.

Pour résoudre ce problème, il est judicieux modifier l'enregistrement DNS pour le nom d'ordinateur hôte PWA et pointez-le temporairement sur un serveur frontal unique. De cette manière vous savez quel serveur gère le client demande vous devez uniquement vérifier les fichiers journaux de suivi qui un serveur.

Ouvrir le dernier fichier de journal dans le bloc-notes et la recherche de l'écriture « Impossible d'ouvrir de la base de données. » Si vous trouvez qu'il, vous savez que vous êtes confronté à un problème d'autorisations de base de données. Par exemple, le journal de suivi dans la figure 4 montre que le compte LITWARE\WSS02 $ n'a pas accès à la base de données SharedServices1_DB. Ceci est un indicateur Effacer qui le site PWA s'exécute avec une identité de service réseau.

LITWARE\WSS02 $ est le compte d'ordinateur du serveur Web frontal et SharedServices1_DB est la base de données du fournisseur de services partagés. Entre autres choses, les serveurs frontaux Web utiliser cette base de données afin de conserver les données d'état de session ASP.NET de la table ASPStateTempSessions, mais $ LITWARE\WSS02 n'a pas accès à cette base de données.

Il est important de noter que vous devez vous assurer de que vous incluez de base de données du fournisseur de services partagés dans vos activités de maintenance de base de données hebdomadaire pour garantir des performances système stable. Par exemple, vous devez supprimer session expirée données d'état de la table ASPStateTempSessions à l'aide de la SQL commande Vider ASPStateTempSessions de TABLE, comme indiqué dans » Déployer Project Server 2007 vers un environnement de batterie de serveurs."

Problèmes de configuration liées de service réseau peuvent être déroutant, donc je vais examiner un plus près les. Comptes de domaine (tels que LITWARE\SspConfig­Admin) fonctionnent pour les pools d'applications de batteries de serveurs car elles sont exactement les mêmes sur tous les ordinateurs. En revanche, le compte Service réseau (NT AUTHORITY\­NETWORK SERVICE) est différent sur chaque ordinateur unique. Sur un serveur frontal est nommé wss02.litware.com, le compte NT AUTHORITY\NETWORK SERVICE traduit LITWARE\WSS02 $. Mais sur un serveur avec la sql01.litware.com nom, le compte NT AUTHORITY\­NETWORK SERVICE désigne LITWARE\SQL01 $ au lieu de cela. Il se trouve le problème.

Si vous examinez les autorisations SQL Server pour SharedServices1_DB dans SQL Server Management Studio, vous constatez que le compte NT AUTHORITY\NETWORK SERVICE dispose des autorisations db_owner afin d'accorder des pools d'applications qui utilisent l'accès de compte service réseau à la base de données fournisseur de services partagés. Mais n'oubliez pas que cela fonctionne uniquement dans une installation serveur unique.

Vous pouvez résoudre les attributions d'autorisations en accordant explicitement $ LITWARE\WSS02 et tous les autres WSS serveur comptes (peut-être LITWARE\WSS01 $ et so forth) db_owner autorisations pour SharedServices1_DB, mais il est préférable d'utiliser comptes de domaine pour les pools d'applications à la place afin que tous les serveurs frontaux utilisent la même identité que SharePoint a accordé les autorisations de base de données requis.

Autorisations de services partagés

Si votre site PWA pool d'applications utilise le compte service réseau pour une raison quelconque, vous êtes également rencontrer des problèmes SSP-related autorisations. Vous souvenez-vous mentionné que le transfert PSI accède aux les services Web au nom de l'utilisateur dans le contexte du compte du pool d'applications sites PWA de la PSI ? Si ce compte ne possède pas les autorisations d'accès au site de services Office Server Web, vous êtes revenir au carré celui qui a l'habitude message d'erreur SharePoint. Cette fois, le suivi de connecter les états de serveur frontal « la demande a échoué avec état HTTP 401 : Non autorisé, « tel qu'affiché dans la figure 5 .

La figure 5 la requête a échoué avec l'état HTTP 401 : Non autorisé (Click the image for a larger view)

Gardez à l'esprit que cette erreur ne fait pas référence à autorisations utilisateur dans PWA. SharePoint autorisations accordées dans un site PWA déterminent les utilisateurs peuvent accéder à _VTI_BIN/PSI virtuel sous-répertoire ce site, mais ces utilisateurs ne reçoivent pas autorisations d'accès à l'application Shared Services Web ou les services PSI Web sur le serveur d'applications.

Même si vous êtes un administrateur de collection de sites PWA, MOPS échoue encore Si compte du pool d'applications le site PWA n'a pas accès aux services Web PSI. Ceci est particulièrement le cas si vous ignorez la recommandation d'utiliser des comptes de domaine pour les pools d'applications dans une batterie de serveurs et d'utiliser le compte service réseau au lieu de cela.

Pour vérifier autorisations d'accès du fournisseur de services partagés (SSP) sur le serveur d'applications, extraire le fichier web.config dans le répertoire racine du site Office Server Web services (par défaut, %PROGRAMFILES%\­Microsoft Servers\12.0\Web­Services\Root Office). Vous pouvez remarquer l'entrée NT AUTHORITY\NETWORK SERVICE dans la section <authorization>, qui est censée pour autoriser les pools d'applications qui utilisent le compte service réseau. Mais là encore, il n'est pas accomplir la tâche car l'écriture fait référence uniquement à l'ordinateur local, qui n'est pas le serveur frontal.

La meilleure stratégie consiste à modifier la configuration de pool d'application et utiliser un compte de domaine. Mais si vous insist en utilisant le compte service réseau, vous devez autoriser explicitement les comptes de serveur frontal.

Ne pas modifier le fichier web.config sur le serveur d'applications directement, SharePoint remplacera vos modifications. Au lieu de cela, utilisez l'administration centrale de SharePoint 3.0 pour accorder les autorisations manquantes, comme indiqué dans la feuille de calcul « test partage service fournisseur autorisations d'accès ». En outre, vérifiez la configuration en utilisant une application ASP.NET simple qui établit une connexion HTTP directe avec les services Web PSI, tels que SSPCheck (qui est inclus dans le matériel associé). Assurez-vous simplement qu'exécuter l'application test ASP.NET sous le site PWA pool d'applications pour obtenir des résultats fiables.

Le pare-feu Windows

À ce stade, il est probable Qu'est bien que vous pouvez ouvrir PWA, sauf si bien entendu, vous tentez d'accéder PWA par le biais d'un serveur frontal Web et le pare-feu Windows sur le serveur d'applications MOPS bloque les ports TCP 56737 et 56738. Voici les ports par défaut affectés au site Office Server Web services pour la communication HTTP et HTTPS.

SharePoint n'ouvre ces ports automatiquement sur le serveur d'applications MOPS lorsque vous créez le site de services Office Server Web. Si vous avez pare-feu Windows est activé sur le serveur d'applications, vous devez créer manuellement une règle de pare-feu pour autoriser le trafic vers ces ports pour que les serveurs frontaux puissent accéder les services Web PSI. Si un pare-feu bloque ces ports, vous recevez le message d'erreur affichées dans Figure 6 et le journal de suivi n'états serveur frontal de « ordinateur hôte connecté a pas répondu. »

La figure 6 Project Web Access ne peut pas se connecter à Project Server (cliquez sur l'image pour l'agrandir)

MOPS services et comptes de service

Avoir résolu les problèmes de communication frontal/principal, vous devriez pouvoir pour accéder à Project Web Access. Félicitations ! Maintenant, il est temps pour vous concentrer sur un problème spécifique de MOPS plus difficile. Prendre un changement en profondeur et puis ouvre le journal des événements application sur votre serveur d'applications MOPS et n'est pas shocked si vous voyez des milliers et des milliers de messages d'erreur indiquant que la file d'attente « de système n'a pas pu démarrer," comme illustré figure 7 . Vous pouvez également remarquer que services MOPS entraîner un presque 100 % UC.

La figure 7 de la file d'attente système Impossible de démarrer (cliquez sur l'image pour l'agrandir)

Le système de file d'attente est la colonne vertébrale de l'infrastructure d'application MOPS pour MOPS de base de données insérer et mettre à jour de demande de traitement, nettoyage et la gestion des traitements et base de données pour la mise à jour le rapport de pour une utilisation dans les données tâches d'analyse. Cela est expliqué dans façon très détaillée dans l'article » Microsoft Office Project Server 2007 Queuing System." En fonction de cet article, le système de file d'attente repose sur un service Windows, implémenté dans l'assembly Microsoft.Office.Project.Server.Queuing.exe et exécuté sous l'identité du SharePoint configuration administration et de minuteur compte de service pour accéder à configuration base de données la batterie.

Au démarrage, le service Windows récupère la liste de tous les fournisseurs de services partagés à partir de la base de données de configuration, y compris les comptes d'administrateur du fournisseur de services partagés (SSP) correspondants et leurs mots de passe chiffrés, puis démarre un processus Microsoft.Office.Project.Server.Queuing.exe supplémentaire pour chaque fournisseur de services partagés associé aux sites PWA dans le contexte du compte administrateur du fournisseur de services partagés (SSP) correspondant. En d'autres termes, Microsoft.Office.Project.Server.Queuing.exe démarre plusieurs instances d'elle-même sous différents comptes, le nombre total de Microsoft.Office.Project.Server.Queuing.exe processus s'exécutant sur un serveur d'applications MOPS est égal au nombre de fournisseurs de services partagés (SSP), plus un.

Les instances d'autres processus sont les processus de travail file d'attente. Chaque processus de travail chaque file d'attente définit son propre ensemble de sites PWA de son SSP associé, démarre les threads d'interrogation distinct pour chacun des sites PWA et commence le traitement que les tâches en attente des bases de données correspondantes de site PWA. C'est le fonctionnement du système file d'attente, et vous pouvez vérifier cela dans le Gestionnaire des tâches Windows.

Sur un serveur d'application MOPS d'une batterie de serveurs avec un fournisseur de services partagés associé sites PWA, vous pouvez afficher deux processus Microsoft.Office.Project.Server.Queuing.exe — une exécution en tant que compte d'administration configuration et la autre exécuté comme compte d'administrateur du fournisseur de services partagés (SSP). Dans mon environnement de test, ces comptes trouvent WssConfigAdmin et SspConfig­Admin, comme présenté dans la figure 8 .

La figure 8 Inter-process communication échoue car l'accès est refusé (cliquez sur l'image pour l'agrandir)

Ainsi, pourquoi n'est pas le système de file d'attente de commencer ? L'entrée d'erreur dans le journal des événements d'application ne fournit pas suffisamment d'informations, mais vous pouvez obtenir plus d'informations si vous définissez temporairement les événements critiques moins rapport pour le journal de suivi pour toutes les catégories commentaires dans l'administration centrale de SharePoint 3.0 dans l'onglet opérations sous enregistrement des diagnostics.

La figure 8 illustre un journal de suivi qui en résulte, et si vous jetez un œil plus près, vous pouvez voir que le ProjectQueueService (le service fenêtre global) démarre un QueueExecService (un processus de travail file d'attente), mais le processus QueueExecService échoue car l'accès est refusé. Comme QueueExecService échoue, ProjectQueueService tente de redémarrer, mais il échoue à nouveau pour la raison même très, et donc il continue de consommation de cycles de processeur et l'événement de remplissage et le suivi journaux avec des milliers d'erreurs. Il s'agit d'une boucle infinie.

Malheureusement, même le journal de suivi plus détaillé n'affiche pas que la cause spécifique de l'accès est refusée erreur. Mais ne despair, dans le processus d'élimination, vous pouvez accéder rapidement à la cause.

Si vous modifiez le compte administrateur du fournisseur de services partagés (SSP) dans l'administration centrale de SharePoint 3.0 et que vous spécifiez le compte d'administration configuration (WssConfigAdmin), le système de file d'attente démarre. Elle fonctionne également l'autre sens ; si vous laissez simplement le compte d'administrateur du fournisseur de services partagés (SSP) inchangée (SspConfigAdmin) et utilisez-la en tant que compte de service pour le service Windows, la file d'attente système démarre ainsi.

Il suit ensuite que les le compte d'administration configuration et le compte d'administrateur du fournisseur de services partagés (SSP) ont toutes les autorisations requises ; il est simplement que le système de file d'attente ne démarre pas si Project­QueueService et QueueExecService utilisent des comptes différents.

Ceci est un indicateur Effacer d'un problème autorisations entre des processus distincts pour interagir avec eux sur l'ordinateur local. Après tout, les processus ProjectQueueService et QueueExecService doivent surveiller eux pour garantir un comportement cohérent service (Notez les entrées Process­Watcher dans la trace de se connecter figure 8 ). Par exemple, lorsque vous arrêtez le service Windows ProjectQueueService, tout processus de travail QueueExecService doivent arrêter ainsi.

Il est la tentative d'accès un processus qui s'exécute dans un contexte de sécurité qui entraîne l'erreur. Accéder à un processus dans un autre contexte de sécurité requiert des privilèges élevés. Refuse même si les comptes de service peuvent dispose de ces privilèges, Windows Server 2008 toujours l'accès car le contrôle (compte d'utilisateur est activé par défaut, ce qui entraîne le processus à exécuter avec privilèges standard.

Dès que vous désactivez le contrôle de compte d'utilisateur, processus ProjectQueueService et QueueExecService peuvent s'exécuter avec des privilèges élevés et le système de file d'attente démarre. Le choix est bien entre utilisez le compte d'administration configuration comme le compte d'administrateur pour tous les fournisseurs de services partagés, ainsi, exécution de tous les processus de file d'attente avec le même compte ou weakening sécurité sur vos serveurs d'applications MOPS en désactivant le contrôle de compte d'utilisateur.

Ressources SharePoint

Les produits et technologies Web site SharePoint
Microsoft.com/SharePoint

Windows SharePoint Services TechCenter
technet.microsoft.com/WindowsServer/SharePoint

Centre de développement Windows SharePoint Services
MSDN.Microsoft.com/SharePoint

Référence Microsoft Office Project 2007 général
MSDN.Microsoft.com/library/bb258902

Produits et Microsoft SharePoint technologies blog de l'équipe
blogs.msdn.com/SharePoint

Planification de comptes d'administration et de service (Office SharePoint Server)
technet.microsoft.com/library/cc263445

Intégration des services d'analyse

Nous allons conclure de cette colonne avec un problème de SQL Server 2005 Analysis Services qui vous êtes susceptible de rencontrer si vous suivez les instructions décrites dans » Configuration requise pour utiliser SQL Server 2005 Analysis Services avec le service Project Server 2007 cube création"(du 2007-04-05 au moment de cet article). Si vous suivez le chemin d'accès créer le référentiel Analysis Services en créant une base de données SQL Server 2005 comme indiqué, vous vous retrouver avec l'erreur affichée dans la figure 9 lorsque vous tentez de créer le cube dans PWA.

La figure 9 cube création erreur due à Analysis Services mauvaise configuration (cliquez sur l'image pour l'agrandir)

Le point important est que MOPS 2007 est conçu pour SQL Server 2000 Analysis Services. SQL Server 2005 Analysis Services nécessite des étapes de configuration supplémentaires pour compatibilité descendante. La version de SQL Server 2000 stocke référentiel d'informations sur la création de cube dans une base de données Microsoft Jet et bien qu'il soit possible de migrer une base de données Jet pour travailler avec SQL Server 2005, il n'est pas nécessaire dans un déploiement MOPS nouvelle.

L'article de TechNet auquel J'AI simplement référence explique comment configurer SQL Server 2005 pour émuler la fonctionnalité de la base de données Jet indépendamment d'ou non la base de données Jet en réalité actuelle. L'article correspondant échoue encore, indiquez que MOPS vérifie toujours référentiel de verrouillage des informations dans le partage de fichiers .DSO sur le serveur de base de données Si Analysis Services est configuré pour utiliser une base de données Jet (la méthode ancienne) ou une base de données préconfiguré SQL Server 2005 (qui est la méthode recommandée).

Sauf si ce partage de fichier existe et que le compte d'administrateur du fournisseur de services partagés (SSP) est exprimé accès Contrôle total à ce partage de fichiers, la création de cube échoue avec l'erreur autorisations affichée dans la figure 9 . Pour SQL Server 2005 Analysis Services de la fonction correctement avec le service MOPS de création de cube, suivez les étapes décrites dans la feuille de calcul Compagnon « cubes configuration ».

Conclusion

MOPS 2007 n'est pas facile à déployer. L'architecture est complexe et un déploiement réussi implique plusieurs étapes, allant de la bonne planification des configurations de batterie de serveur, l'installation des fichiers binaires et l'exécution les produits SharePoint Assistant Configuration des et technologies sur applications serveurs et serveurs Web frontaux via la création de pools d'applications, services partagés, sites d'administration du fournisseur de services partagés et sites PWA de l'administration centrale de SharePoint 3.0, à la configuration enfin d'Analysis Services dans SQL Server Management Studio.

Qui contribuent aux difficultés du déploiement interfèrent fonctionnalités de sécurité de Windows Server 2008, telles que le pare-feu Windows et le contrôle de compte d'utilisateur, des points faibles dans les outils Administration SharePoint et omissions dans la documentation de déploiement MOPS. Vous ne pouvez pas compter sur l'administration centrale de SharePoint 3.0 pour avertir vous si vos pools d'applications utilisez le compte Service réseau dans une batterie de serveurs, appliquer toutes les modifications de configuration requise automatiquement (tels que liaisons de site de services Internet (IIS) et les règles de pare-feu Windows), ou vérifiez l'état opérationnel des sites PWA mis en service.

En outre, ne pensez pas que tout fonctionne de la zone. Assurez-vous que vous entièrement comprendre l'architecture de MOPS et les dépendances, ne pas dévier de recommandations de produit et soigneusement Valider la configuration MOPS et fonctionnalité en créant tester les plans de projets et ressources pour garantir la réussite du déploiement.

Malgré ces défis, MOPS hérite également les atouts de SharePoint comme une plate-forme d'entreprise. À compter sur les technologies de services Web et de SharePoint, MOPS élimine le besoin de connectivité de base de données directement sur les stations de travail clientes. Dans le système de file d'attente, MOPS augmente sustainability pendant les heures de pointe (pour une raison quelconque unexplainable, tous les responsables de programme voulez mettre à jour leurs plans de projet sur lundi matin), et à d'autres technologies MOSS, il est possible intégrer MOPS avec davantage de métier applications.

Avoir développé des solutions métier pour Project Server 2003 dans le passé, J'AI rechercher la minuscule MOPS 2007 déploiement défis en comparaison aux dernières évolutivité problèmes, les problèmes de connectivité ODBC anciens sur les connexions réseau lentes, et la difficulté de création de requêtes de base de données qui impliqués tellement JOIN instructions qui je devaient utiliser Excel pour effectuer le suivi de toutes les requêtes sub. MOPS 2007 est un jalon significatif dans l'évolution EPM, et il est important de l'effort de déploiement.

Pav Cherny est un expert informatique et l'auteur spécialisé dans les technologies Microsoft de collaboration et de communication unifiée. Son compositions incluent les blancs, produit manuels et livres avec une spécialisation sur les opérations INFORMATIQUES et d'administration système. Pav est président de Biblioso Corporation, une entreprise spécialisée dans les services de documentation et de localisation gérés.