All'interno di SharePoint Gestione del progetto dell'organizzazione con SharePoint

Pav Cherny

Contenuto

Architettura di server di progetto
Integrazione con SharePoint
Distribuzioni di server farm
Per IIS 7
Le autorizzazioni del database di sessione
Autorizzazioni di servizi condivisi
Windows Firewall
MOPS servizi e degli account di servizio
Integrazione con servizi di analisi
Conclusione

Quali le tecnologie SharePoint sono adatta? Nel lavoro per trovare la risposta è stato probabilmente sifted in un elenco di categorie, apparentemente innumerevoli inclusi collaborazione utenti area di lavoro riunioni eventi sociali, i portali, ricerca Enterprise, gestione contenuto aziendale, processi aziendali e form, Business Intelligence e funzionalità di piattaforma per sviluppatori e confrontare le funzionalità disponibili in Windows SharePoint Services (WSS) 3.0, Microsoft Office ricerca Server 2008 Express, Microsoft Office Forms Server 2007 e Microsoft Office SharePoint Server (MOSS) 2007. Tuttavia, di una tecnologia potrebbe non sono considerati in quanto Microsoft non elencare in SharePoint prodotti e tecnologie, Enterprise Project Management (EPM) che viene attivata tramite Microsoft Office Project Server (MOPS) 2007.

Ma MOPS 2007 è tecnologia SharePoint; si basa sui ed estende WSS 3.0 in modo che è paragonabile a MOSS 2007. MOPS 2007 è la scelta giusta se si desidera aumentare l'efficienza di collaborazione di team all'interno e tra i reparti lavoro, delle risorse e Gestione budget oltre le capacità lightweight gestione attività incluse nella WSS 3.0 e MOSS 2007. Con MOPS, è possibile trasformare i siti del team in aree di lavoro dei progetti, gestire la collaborazione dei team all'interno e tra i reparti e definire una solida base EPM per un'intera organizzazione. In primo luogo, tuttavia, è necessario master i problemi di distribuzione.

In questo articolo, è possibile discutere la distribuzione di MOPS 2007 in un ambiente Windows Server 2008 con SQL Server 2005 SP2 e WSS 3.0 SP1. Innanzitutto, brevemente esaminare l'architettura MOPS per visualizzare il modo in cui i componenti di integrano con WSS 3.0 dal punto di vista un architetto di sistema. Queste informazioni semplifica di seguire la discussione successiva di distribuzione tipica e problemi di integrazione che possono verificarsi, ad esempio problemi di configurazione pool di applicazioni, autorizzazioni di accesso di mancanti, gli errori di avvio del sistema coda e problemi relativi a SQL Server 2005 Analysis Services.

Per illustrare la distribuzione e risoluzione dei problemi passaggi, è possibile utilizzare un ambiente di prova di base con due server WSS 3.0 in una server farm, un controller di dominio dedicato, e un computer separato che esegue SQL Server, simile a un ambiente di test È stato stato utilizzando finora per questa colonna di SharePoint. È possibile trovare fogli di lavoro corrispondente con istruzioni dettagliate nel materiale di accompagnamento per questo articolo, presente nel sito Web TechNet Magazine.

Architettura di server di progetto

MOPS 2007 è una delle applicazioni di SharePoint più avanzate e complesse. Sfrutta completa la piattaforma di WSS 3.0 per l'amministrazione centralizzata, provisioning del sito, autenticazione e protezione. Inoltre, vengono aggiunti ulteriori componenti, come 25 generale e specializzati MOPS Web part e un nuovo insieme di fino a quattro database MOPS per sito di Project Web Access (PWA). Ogni avviene tramite un insieme di 21 pubblici e interni MOPS Web servizi che insieme costituiscono Project Server Interface (PSI), come illustrato nella Figura 1 . È possibile trovare ulteriori informazioni su MOPS servizi Web su MSDN.

Nella figura 1 Integrazione con SharePoint 2007 MOPS fare clic su Immagine per una visualizzazione ingrandita

L'architettura MOPS 2007 si basa su una varietà di componenti distribuiti client workstation, server applicazioni e server di database. È possibile esaminare il più importante di questi componenti in questa colonna, ma se si desidera tutti i dettagli tecnici, leggere il " Architettura di server di progetto"documentazione in Project 2007 SDK.

Solo tenere presenti quando si lettura SDK che PWA Web part e il Microsoft Office Project Professional 2007 non accedono i servizi Web di PSI direttamente. L'SDK suggerisce che i client di effettuare chiamate dirette a PSI, ma la maggior parte delle applicazioni effettivamente utilizzare server d'inoltro PSI che è un componente in siti PWA che fornisce accesso indiretto ai servizi Web di PSI. Solo basate su server componenti, quali il servizio di coda e il servizio eventi, che vengono eseguiti con autorizzazioni system-level effettuare chiamate PSI dirette. Questo particolare poco è importante tenere presente nella risoluzione dei casi per vari motivi, in particolare:

• Siti PWA definiscono il contesto di database (ogni singolo sito PWA ha separati bozza pubblicato, archivio, database e report) e autorizzazioni utente, ma gli account utente standard non autorizzati ad accedere ai servizi Web di PSI.
• Server d'inoltro PSI non supporta la rappresentazione e utilizza account pool di applicazioni del sito PWA per i servizi Web PSI per conto di utenti di accedere a.
• Chiamate PSI non utilizzare necessariamente servizi Web di PSI locali se la farm include più istanze di applicazione server.

Integrazione con SharePoint

Ora Diamo un sguardo più da vicino al effettivo MOPS Integrazione con SharePoint. Dal punto di vista un amministratore di SharePoint, MOPS è un'applicazione Web condivisa gestita come un servizio di farm in Amministrazione centrale SharePoint 3.0. Ciò è relativamente semplice per gli amministratori esperti condivisi provider di servizi (SSP) di MOSS 2007.

Ma se di amministratore di WSS 3.0 e nuovo amministrazione provider di servizi CONDIVISI, si verrà desidera di estrarre il foglio di "distribuzione Project Server 2007" lavoro, disponibile nel materiale di accompagnamento, per istruzioni dettagliate per creare e configurare servizi condivisi e PWA una farm SharePoint siti. Dopo l'installazione MOPS e la configurazione, è possibile analizzare l'implementazione del sistema in Gestione IIS. Come illustrato nella Figura 2 , si deve vedere separato Web sites for servizi condivisi, l'amministrazione provider di servizi CONDIVISI e raccolte siti in un server applicazioni MOPS.

Nella figura 2 accesso Project Server 2007 tramite PWA e server d'inoltro PSI fare clic su Immagine per una visualizzazione ingrandita

I client accedere i servizi Web di PSI tramite la directory virtuale _VTI_BIN/PSI in un sito PWA. Tuttavia, i servizi Web di PSI non risiedono in questa directory virtuale. La directory virtuale _VTI_BIN/PSI esegue il mapping il percorso fisico seguente: % COMMONPROGRAMFILES %\Microsoft Shared\web server Extensions\12\ISAPI\PSI. Si noterà che questa directory contiene un file web.config che specifica in una sezione <http­Handlers> che tutte le richieste HTTP a file *.asmx (, servizi Web basate su ASP.NET) devono essere passate un gestore HTTP personalizzato, creare un'istanza tramite Micro­soft.Office.Project.Server.PSIForwarder­HandlerFactory.

Il gestore HTTP personalizzato è server d'inoltro PSI. Server d'inoltro PSI stabilisce una connessione HTTP nuova a servizi Web di PSI effettivi, inoltra la richiesta del client HTTP e quindi restituisce i risultati al client.

I servizi Web di PSI sono disponibili per server d'inoltro PSI tramite HTTP tramite la directory virtuale PSI dell'applicazione Web di servizi condivisi, cui è ospitato nel sito di servizi Web di Office Server. Questa directory virtuale esegue il mapping per impostazione predefinita il %\Microsoft di percorso fisico % PROGRAMFILES Servers\12.0\WebServices\Shared\PSI Office e questo rappresenta in cui è possibile trovare i file *.asmx MOPS 2007.

È possibile verranno illustrate più sul sito servizi Web di Office Server in seguito, per ora, il fatto più importante per rendere opposta Nella figura 2 è che il server d'inoltro PSI si comunica con i servizi Web di PSI utilizzando l'identità dell'account pool di applicazioni Web del sito PWA invece dell'utente attualmente l'accesso al sito PWA.

Distribuzioni di server farm

Server d'inoltro PSI anche svolgono un ruolo importante nelle distribuzioni di farm di server utilizzare server front-end Web distinti e server applicazioni per aumentare la scalabilità del sistema e disponibilità. Un server front-end MOPS è un server WSS 3.0 che non host i servizi PSI Web o altri servizi MOPS such as servizio di coda e il servizio eventi) ma fornisce client con accesso ai siti PWA, che includono PSI Forwarder, come illustrato nella Figure 3 .

Nella figura 3 A dimensioni medie MOPS 2007 server farm fare clic su Immagine per una visualizzazione ingrandita

Un server applicazioni, invece, è un server di WSS 3.0 con l'insieme completo di MOPS componenti e servizi installati. Server applicazioni possono siti host PWA, ma più spesso di non sono solo servizi back-end a server front-end e non eseguire il servizio di applicazione Web WSS. È possibile scegliere il ruolo del server durante l'installazione MOPS.

Nella figura 3 viene illustrata la configurazione per una dimensione supporto server farm. È possibile aggiungere ulteriori server front-end per aumentare la scalabilità e come server applicazioni aggiuntive per la disponibilità elevata, a seconda requisiti dell'organizzazione. Non è necessario configurare un cluster di bilanciamento del carico per server applicazioni MOPS perché il server d'inoltro PSI automaticamente carico saldi PSI richieste Se più server di applicazioni MOPS esiste nel server farm. Per informazioni dettagliate riguardanti le opzioni di distribuzione MOPS, vedere il " Guida alla distribuzione di Office Project Server 2007."

Per IIS 7

Sufficiente teoria! Affrontiamo alcuni problemi reali che possono verificarsi durante la distribuzione di MOPS 2007. Uno dei problemi mio Preferiti è correlata a raccolte di siti basati su host per i siti PWA. In questo scenario correttamente MOPS di distribuire, configurare SSP, il provisioning di un sito PWA in modalità di intestazione host dall'immettendo l'URL di PWA completo (ad esempio pwa dopo aver selezionato il percorso di utilizzare Project Web Access come casella di controllo Consenti intestazione host nella pagina Crea sito di Project Web Access. Quindi, dopo tutte le risorse sono provisioning correttamente, si tenta di aprire il sito ma, anziché PWA, schermata la standard IIS 7 iniziale.

Si tratta di cosa accade se il sito Web predefinito non è esteso SharePoint ed è presente nessun altro sito Web con un'associazione sito appropriato per l'URL PWA. Senza un'associazione esplicita di sito, IIS associa la richiesta pwa con non estese sito Web predefinito, in modo da conoscere la schermata iniziale. Potrebbe avere previsto Amministrazione centrale SharePoint 3.0 per aggiungere l'associazione necessario per l'applicazione Web di SharePoint che sono selezionate per host PWA il sito, ma non eseguita.

Per risolvere questo problema, è necessario estendere il sito Web predefinito di SharePoint e si quindi utilizzare questa raccolta siti per accantonamento PWA siti, come descritto in un foglio di risoluzione dei problemi di IIS e PWA complementare lavoro. In alternativa, è possibile aggiungere l'associazione di sito mancanti manualmente in Gestione Internet Information Services all'applicazione Web selezionata per PWA. Non dimenticare di eseguire questo passaggio su tutti i server WSS host PWA il sito.

Le autorizzazioni del database di sessione

Se si decide di estendere il sito Web predefinito, assicurarsi di utilizzare un account di dominio per il pool di applicazioni, vedere " Pianificazione per l'amministrazione e Service account Office SharePoint Server", in caso contrario, si verificheranno problemi correlati autorizzazione dopo provisioning PWA siti, in genere manifestarsi se stessi in un messaggio di errore di SharePoint in genere uninformative ad come quello visualizzato nel Nella figura 4 .

Nella figura 4 errore di accesso al database di provider di servizi CONDIVISI fare clic su Immagine per una visualizzazione ingrandita

Per trovare le informazioni più significative, è necessario estrarre i registri di traccia nella directory % COMMONPROGRAMFILES %\­Microsoft Shared\web server Exten­sions­\12\LOGS. Può trattarsi di un'attività noiosa se della server farm include più server front-end Web il carico bilanciato.

Per la risoluzione dei problemi, è consigliabile modificare il record DNS per il nome host PWA e scegliere temporaneamente un unico server front-end. In questo modo si è certi che server gestisce il client richiede quindi è necessario controllare il file di registro di traccia che un server.

Aprire il file di registro più recente in Blocco note e individuare per la voce Impossibile aprire l'database. Se disponibile, si sa che si utilizzano un problema di autorizzazioni del database. Ad esempio, nel log dell'analisi nella Figura 4 viene mostrato che l'account LITWARE\WSS02 $ non ha accesso al database SharedServices1_DB. Questo è un chiaro indicatore il cui il sito PWA è in esecuzione con un'identità di servizio di rete.

$ LITWARE\WSS02 è l'account computer del server Web front-end e SharedServices1_DB è il database di provider di servizi condivisi. Tra le altre cose, i server front-end Web utilizzare il database per mantenere i dati di stato sessione ASP.NET nella tabella ASPStateTempSessions, ma LITWARE\WSS02 $ non dispone dell'accesso al database.

È importante tenere presente che è necessario assicurarsi di che includere il database di provider di servizi condivisi nelle attività di manutenzione database settimanali per garantire le prestazioni del sistema stabile. Ad esempio, è necessario rimuovere sessione scaduti i dati dello stato della tabella ASPStateTempSessions utilizzando il codice SQL comando TRUNCATE TABLE ASPStateTempSessions, come documentato in" Distribuire Project Server 2007 in un ambiente server farm."

Problemi di configurazione correlate servizio di rete possono generare confusione, quindi mi intende esaminare più da vicino le. Account di dominio (ad esempio LITWARE\SspConfig­Admin) funzionare per pool di applicazioni nella server farm in quanto sono esattamente uguali in tutti i computer. Invece, l'account Servizio di rete (NT AUTHORITY\­NETWORK SERVICE) è diverso in ogni singolo computer. In un server front-end è denominato wss02.litware.com l'account NT AUTHORITY\NETWORK SERVICE converte in LITWARE\WSS02 $. Ma in un server con sql01.litware.com il nome, l'account NT AUTHORITY\­NETWORK SERVICE intende $ LITWARE\SQL01 invece. Vi risiede il problema.

Se si esaminano le autorizzazioni SQL Server per SharedServices1_DB in SQL Server Management Studio, consente di verificare che l'account NT AUTHORITY\NETWORK SERVICE disponga di autorizzazioni db_owner nel tentativo di concedere il pool di applicazioni che utilizzano all'account servizio di rete l'accesso al database di provider di servizi condivisi. Ma si tenga presente che funziona solo in un'installazione a server singolo.

Per risolvere le assegnazioni delle autorizzazioni, concedere esplicitamente LITWARE\WSS02 $ e tutte le altre WSS server account (ad esempio $ LITWARE\WSS01 e so forth) db_owner autorizzazioni per SharedServices1_DB, ma è preferibile utilizzare account di dominio per pool di applicazioni invece in modo che tutti i server front-end utilizzano la stessa identità SharePoint dispone le autorizzazioni di database necessari.

Autorizzazioni di servizi condivisi

Se il pool di applicazioni del sito PWA utilizza l'account Servizio di rete per qualsiasi motivo, si verificheranno anche problemi di autorizzazioni SSP-related. Ricordare che detto che server d'inoltro PSI accede a servizi Web di PSI per conto dell'utente nel contesto dell'account del pool PWA siti dell'applicazione? Se questo account non dispone di autorizzazioni per l'accesso al sito Servizi Office Server Web, stai nuovamente all'quadrato con il normale messaggio di errore SharePoint. Questa volta, l'analisi accedono gli stati del server front-end " la richiesta non riuscita con stato HTTP 401: non è autorizzato, " così come visualizzata nella Figura 5 .

Nella figura 5 la richiesta non riuscita con stato HTTP 401: (Click the image for a larger view) accesso

Tenere presente che questo errore non fa riferimento a autorizzazioni utente in PWA. SharePoint autorizzazioni concesse in un sito PWA determinano quale poter accedere a sottodirectory virtuale _VTI_BIN/PSI tale sito, ma gli utenti non ricevono autorizzazioni di accesso all'applicazione Shared Services Web o i servizi PSI Web del server applicazioni.

Anche se si è un amministratore della raccolta siti PWA, MOPS non riesce comunque se applicazione pool account il sito PWA non disponga Nessun accesso i servizi Web di PSI. Questo avviene soprattutto se si ignora il consiglio di utilizzare account di dominio per pool di applicazioni di una server farm e utilizzare invece l'account di servizio di rete.

Per verificare il provider di servizi CONDIVISI autorizzazioni di accesso del server applicazioni, estrarre il file web.config nella directory principale del sito di servizi Web di Office Server (per impostazione predefinita, %PROGRAMFILES%\­Microsoft Servers\12.0\Web­Services\Root Office). È possibile notare la voce di NT AUTHORITY\NETWORK SERVICE nella sezione <authorization>, che dovrebbe per autorizzare i pool di applicazioni che utilizzano l'account di servizio di rete. Ma anche in questo caso, non eseguire l'attività perché il movimento si riferisce solo al computer locale, che non è il server front-end.

La strategia migliore consiste nel modificare la configurazione pool di applicazione e utilizzare un account di dominio. Ma se richiedere utilizzando l'account di servizio di rete, è necessario autorizzare l'account del server front-end in modo esplicito.

Non modificare direttamente il file web.config del server applicazioni, le modifiche verranno sovrascritte SharePoint. Utilizzare invece Amministrazione centrale di 3.0 di SharePoint per concedere autorizzazioni mancanti, come descritto in "test condivisa servizio provider di accesso autorizzazioni" foglio di lavoro. Inoltre, è possibile verificare la configurazione utilizzando un'applicazione ASP.NET semplice che stabilisce una connessione diretta HTTP ai servizi Web di PSI, ad esempio SSPCheck (che è inclusa nel materiale di accompagnamento). Verificare che si esegue l'applicazione di test ASP.NET in pool di applicazioni del sito PWA per ottenere risultati affidabili.

Windows Firewall

A questo punto, sono utili che è possibile aprire PWA probabilità, a meno che, naturalmente, si sta tentando di accedere PWA tramite un server front-end Web e il firewall di Windows del server applicazioni MOPS blocca le porte TCP 56737 e 56738. Questi sono le porte predefinite assegnate al sito Web di Office Server servizi per le comunicazioni HTTP e HTTPS.

SharePoint non aprire queste porte automaticamente nel server di applicazione MOPS creazione del sito di servizi Web di Office Server. Se disponi di Windows Firewall attivato sul server dell'applicazione, è necessario creare manualmente una regola del firewall per consentire il traffico verso queste porte in modo che i server front-end possono accedere i servizi Web di PSI. Se un firewall blocca queste porte, riceverai il messaggio di errore visualizzato in figura 6 e il log di traccia degli stati server front-end "host connesso non risponde."

Nella figura 6 Project Web Access non può connettersi a Project Server fare clic su Immagine per una visualizzazione ingrandita

MOPS servizi e degli account di servizio

Se risolto i problemi di comunicazione front-end/back-end, sarà possibile accedere a Project Web Access. Congratulazioni. È ora possibile concentrarsi su un problema specifico MOPS più difficile. Richiedere una completa attendere e quindi aprire il registro eventi applicazioni del server di applicazioni MOPS e non shocked se viene visualizzato migliaia e delle migliaia di messaggi di errore indicante che la "coda Impossibile avviare il sistema," come illustrato nella Figura 7 . È anche possibile notare che servizi MOPS causare un utilizzo della CPU quasi al 100 %.

Nella figura 7 Impossibile avviare la coda di sistema fare clic su Immagine per una visualizzazione ingrandita

Il coda sistema backbone dell'infrastruttura di applicazione MOPS per MOPS database inserire e aggiornare la gestione di richiesta in esecuzione processi di pulitura e la manutenzione e per aggiornare il report database per l'utilizzo in dati attività di analisi. Questo è descritto in dettaglio ottima nell'articolo" Microsoft Office Project Server 2007 Accodamento System." In base a questo articolo, il sistema di coda si basa su un servizio di Windows, implementato in assembly Microsoft.Office.Project.Server.Queuing.exe e viene eseguito con l'identità Dell'sharepoint configurazione Amministrazione e del timer servizio account per accedere database di configurazione della farm.

All'avvio, il servizio Windows recupera l'elenco di tutti i provider di servizi condivisi dal database di configurazione, inclusi gli account di amministratore del provider di servizi CONDIVISI corrispondenti e le password crittografate e, quindi avvia un processo Microsoft.Office.Project.Server.Queuing.exe aggiuntivo per ogni provider di servizi CONDIVISI associati siti PWA il contesto dell'account amministratore del provider di servizi CONDIVISI corrispondente. In altre parole, Microsoft.Office.Project.Server.Queuing.exe avvia più istanze della stessa con account diversi, in modo che il numero totale di processi Microsoft.Office.Project.Server.Queuing.exe in esecuzione su un server di applicazione MOPS sia uguale al numero di provider di servizi condivisi più uno.

Le istanze di processo aggiuntive sono i processi di lavoro coda. Ogni singola coda processo di lavoro determina un proprio insieme di siti PWA dal relativo provider associato, avvia thread di polling separato per ciascuno dei siti PWA e inizia l'elaborazione che i processi in coda per i database del sito PWA corrispondenti. Ecco come funziona il sistema di coda e si può verificare questo in Task Manager Windows.

In un server di applicazione MOPS di una farm con provider di servizi CONDIVISI associati PWA siti, è possibile visualizzare due processi Microsoft.Office.Project.Server.Queuing.exe, uno in esecuzione come account di amministrazione di configurazione e l'esecuzione come account di amministratore del provider di servizi CONDIVISI. Nell'ambiente di prova questi account sono WssConfigAdmin e SspConfig­Admin, come illustrato nella Figura 8 .

Nella figura 8 Inter-process comunicazione non riesce perché l'accesso verrà negato fare clic su Immagine per una visualizzazione ingrandita

Pertanto, perché non il sistema di coda iniziare? La voce di errore nella registro eventi dell'applicazione non sono disponibili informazioni sufficienti, ma è possibile ottenere ulteriori informazioni se si imposta temporaneamente l'evento critico minimo su report per il registro di traccia per tutte le categorie verbose in Amministrazione centrale di SharePoint 3.0 nella scheda operazioni in registrazione diagnostica.

Figura 8 mostra un log di analisi risultante e se si esegue uno sguardo più da vicino, si possono vedere che ProjectQueueService (generale finestra servizio) avvia un QueueExecService (un processo di lavoro di coda), ma il processo QueueExecService ha esito negativo perché l'accesso è negato. Come QueueExecService ha esito negativo, ProjectQueueService Cerca di riavviare, ma non nuovamente per lo stesso molto motivo, e quindi continua che utilizza i cicli di CPU compilazione l'evento e i registri con migliaia di errori di analisi. Si tratta di un ciclo infinito.

Sfortunatamente, anche più dettagliato registro di traccia non è visibili che la causa specifica dell'accesso viene negata l'errore. Ma non disperare, il processo di eliminazione è possibile accedere rapidamente alla causa principale.

Se è possibile modificare l'account amministratore del provider di servizi CONDIVISI in Amministrazione centrale di SharePoint 3.0, quindi specificare il conto di amministrazione di configurazione (WssConfigAdmin), il sistema di coda inizia. Inoltre funzionamento altri intorno a; Se si lascia semplicemente l'account amministratore di provider di servizi CONDIVISI invariato (SspConfigAdmin) e utilizzarlo come l'account di servizio per il servizio di Windows, la coda viene avviata automaticamente anche.

Posizionarlo quindi che l'account di amministrazione di configurazione e l'account amministratore di provider di servizi CONDIVISI dispongano delle autorizzazioni necessari tutti, ma solo che il sistema di coda non viene avviata se Project­QueueService e QueueExecService utilizzare account diversi.

Questo è un chiaro indicatore di un problema di autorizzazioni tra processi separati desidera interagire tra loro sul computer locale. Dopo tutto, necessario monitorare i processi ProjectQueueService e QueueExecService loro per garantire un comportamento coerente di servizio (si noti l'analisi i movimenti Process­Watcher accedere figura 8 ). Ad esempio, dopo l'arresto del servizio Windows ProjectQueueService eventuali processi di lavoro QueueExecService necessario arrestare anche.

È il tentativo di accedere a un processo in esecuzione in un diverso contesto di protezione che genera l'errore. L'accesso a un processo in un altro contesto di protezione richiede privilegi elevati. Nega anche se gli account di servizio potrebbero dispone di questi privilegi, Windows Server 2008 comunque l'accesso perché controllo account utente (UAC) è attivata per impostazione predefinita, che determina i processi da eseguire con privilegi standard.

Non appena si disattiva il controllo dell'account utente, i processi ProjectQueueService e QueueExecService possono eseguire con privilegi elevati e il sistema di coda avvia. La scelta è proprio tra utilizzando l'account di amministrazione di configurazione come l'account dell'amministratore per tutti i provider di servizi condivisi, pertanto con lo stesso account di tutti i processi di coda o weakening protezione del server di applicazioni MOPS disattivando il controllo dell'account utente.

Risorse di SharePoint

SharePoint Products and Technologies sito
Microsoft.com/SharePoint

TechCenter di Windows SharePoint Services
technet.microsoft.com/windowsserver/SharePoint

Centro per sviluppatori Windows SharePoint Services
msdn.microsoft.com/SharePoint

Riferimento generale di Microsoft Office Project 2007
msdn.microsoft.com/library/bb258902

Prodotti e Microsoft SharePoint blog del team di tecnologie
blogs.msdn.com/SharePoint

Pianificazione per l'amministrazione e Service account Office SharePoint Server
technet.microsoft.com/library/cc263445

Integrazione con servizi di analisi

Possibile concludere questa colonna con un problema di SQL Server 2005 Analysis Services che potrebbero verificarsi se si seguono le istruzioni descritte in" Requisiti per l'utilizzo con il servizio predefinito di Project Server 2007 cubo di SQL Server 2005 Analysis Servicescon Data " (successiva 2007-04-05 al momento di questo articolo). Se si segue il percorso per creare il repository di Analysis Services creando un database di SQL Server 2005, come documentato, corrisponderà alla con l'errore visualizzato nella Figura 9 quando il tentativo di creare il cubo in PWA.

Nella Figura 9 cubo Errore causato da configurazione di Analysis Services non corretta di creazione fare clic su Immagine per una visualizzazione ingrandita

Il punto importante è che MOPS 2007 è stato progettato per SQL Server 2000 Analysis Services. SQL Server 2005 Analysis Services richiede operazioni di configurazione aggiuntive per garantire la compatibilità con le versioni precedenti. La versione di SQL Server 2000 consente di archiviare informazioni del repository relative alla generazione di cubo in un database Microsoft Jet e sebbene sia possibile eseguire la migrazione di un database Jet per l'utilizzo con SQL Server 2005, non è necessario in una distribuzione MOPS aggiornata.

L'articolo di TechNet in cui semplicemente definito viene descritto come configurare SQL Server 2005 per emulazione delle funzionalità del database Jet indipendentemente o meno del database Jet sia effettivamente presente. L'articolo non ancora, citare MOPS controlla comunque archivio informazioni di blocco nella condivisione di file .DSO sul server di database indipendentemente se è configurato Analysis Services per l'utilizzo di un database di Jet (il metodo precedente) o un database SQL Server 2005 preconfigurato (che è il metodo consigliato).

A meno che la condivisione di file esiste e l'account amministratore di provider di servizi CONDIVISI viene concesso accesso Controllo completo la condivisione di file, la generazione del cubo non riesce con l'errore autorizzazioni visualizzata nella Figura 9 . Per SQL Server 2005 Analysis Services alla funzione correttamente con il servizio predefinito di cubo MOPS, seguire i passaggi indicati nella foglio di lavoro complementare "configurazione di cubi".

Conclusione

MOPS 2007 non è facile da distribuire. L'architettura è complessa e una distribuzione riuscita prevede numerosi passaggi, compreso tra pianificazione corretta di configurazioni con server, l'installazione di file binari e l'esecuzione L'sharepoint guidata Prodotti e tecnologie configurazione sui server applicazioni e i server front-end Web, tramite il pool di applicazioni, servizi condivisi, siti di amministrazione provider di servizi CONDIVISI e PWA siti in Amministrazione centrale SharePoint 3.0, il provisioning di infine configurare Analysis Services in SQL Server Management Studio farm.

Contribuire ai problemi di distribuzione creare interferiscono funzionalità di protezione di Windows Server 2008, quali Windows Firewall e controllo dell'account utente, i punti deboli negli strumenti di amministrazione di SharePoint e omissioni nella documentazione di distribuzione MOPS. Non è possibile utilizzare Amministrazione centrale SharePoint 3.0 per avvisare se il pool di applicazioni utilizza l'account di servizio di rete di una server farm, applicare tutte le modifiche di configurazione necessarie automaticamente (ad esempio, le associazioni di sito IIS e le regole del firewall di Windows) o controllare lo stato operativo dei siti di provisioning PWA.

Inoltre, non prevede che tutto lavoro fuori della finestra. Assicurarsi di che comprendere completamente MOPS architettura e le dipendenze, non scostarsi da prodotto consigli e completamente convalidare la configurazione MOPS e funzionalità mediante la creazione di verificare i piani di progetto e le risorse per garantire il successo della distribuzione.

Nonostante queste sfide MOPS eredita i punti di forza di SharePoint come una piattaforma aziendale. Basandosi sulle tecnologie di servizi Web e SharePoint MOPS elimina la necessità per la connettività database diretto sulle workstation client. Attraverso il sistema di coda MOPS aumenta sustainability durante ore di punta (per qualche motivo unexplainable, tutti i manager programma desidera aggiornare i piani di progetto lunedì mattina), e tramite altre tecnologie MOSS, è possibile integrare MOPS con ulteriormente le applicazioni line-of-business.

Avere sviluppato soluzioni aziendali per Project Server 2003 in passato, è possibile individuare il minuscule difficoltà di distribuzione MOPS 2007 in confronto ai problemi scalabilità precedenti, i problemi di connettività ODBC precedenti su connessioni di rete lenta, e problemi di creazione di query di database che interessa molti JOIN istruzioni che era necessario utilizzare Excel per tenere traccia di tutte le query secondaria. MOPS 2007 è un'attività cardine significativa nell'evoluzione EPM e vale la pena di distribuzione.

Cherny Pav è un esperto IT e l'autore specializzato nelle tecnologie Microsoft per la collaborazione e comunicazione unificata. Sua pubblicazioni includono white paper, manuali del prodotto e libri con particolare attenzione su operazioni e amministrazione del sistema. Pav è presidente di Biblioso Corporation, una società specializzata in servizi di documentazione e la localizzazione gestiti.