All'interno di SharePoint Integrare il servizio Information Rights Management di SharePoint
Pav Cherny
Download codice disponibile in: ChernySharePoint2009_05.exe(871 KB)
Contenuto
Produzione di RMS di Active Directory e gerarchie di preproduzione
Topologia di preproduzione RMS di Active Directory
Configurazione di server preproduzione
Problemi relativi alla configurazione IRM di SharePoint
Problemi specifici di preproduzione
Compilazione e registrazione
IRM Protector test
Distribuzione personalizzata protezioni con documenti IRM
Conclusione
Microsoft Office SharePoint Server (MOSS) 2007 viene fornito con le protezioni con basata al framework di Information Rights Management (IRM). Il vantaggio di SharePoint integrazione con Active Directory Rights Management Services (RMS di Active Directory) questi fornire agli utenti di Microsoft Office. Sfortunatamente, Windows SharePoint Services (WSS) 3.0 non include programmi di protezione all'esterno della finestra di IRM. Tuttavia, è una soluzione. Se si passa le applicazioni di esempio e frammenti di codice nella raccolta di codice di MSDN, tra il gems potrai trovare è il Codice sorgente di protezioni con formato file di Microsoft Office, quale Microsoft pubblicato in agosto 2008. Il codice origine proviene con un non esclusiva, tutto il mondo, gratuita " come-è " Microsoft pubblica licenza (Sig.ra PL). Si tratta una ricerca grande in quanto significa è possibile compilare il codice sorgente e aggiungere anche tali componenti a WSS 3.0. In questo modo, è può sfruttare da Active Directory in base RMS protezione e conformità funzionalità in qualsiasi ambiente SharePoint.
In questo articolo, È possibile continuare approfondita ultimo mese integrazione di SharePoint con RMS di Active Directory viene mostrato come creare un ambiente di sviluppo preproduzione RMS di Active Directory, compilare programmi di protezione IRM e integrare i componenti compilati in WSS 3.0. Non effettivamente è necessario un ambiente di preproduzione per compilare programmi di protezione IRM, ma è un esercizio interessante perché evidenziato alcuni errori comuni RMS di Active Directory configurazione che possono verificarsi in un ambiente di produzione. Non è necessario essere uno sviluppatore C o c ++ per comprendere i concetti produzione RMS di Active Directory e gerarchie di preproduzione e sono effetti la distribuzione di RMS di Active Directory, Microsoft Office e WSS 3.0. E non devi di competenze di sviluppo C o c ++ per compilare e test di programmi di protezione IRM. Argomenti di sviluppo, come estendere il codice sorgente o la conversione integrato protezioni con in protezioni con autonomi, sono descritte in questo articolo. L'unica attività di sviluppatore che si verificheranno riguarda la creazione di un progetto di installazione con pochi clic del mouse per semplificare la distribuzione dei componenti di protezione compilate sui server di produzione WSS 3.0. Maggio materiale di accompagnamento (disponibile nella pagina di download del codice della TechNet Magazine) include i fogli di lavoro e strumenti che seguendo la distribuzione, la compilazione e verificare le procedure in computer che eseguono la versione 64 x di Windows Server 2008.
Produzione di RMS di Active Directory e gerarchie di preproduzione
SharePoint, come qualsiasi altra applicazione che desideri utilizzare RMS di Active Directory per crittografare o decrittografare il contenuto, deve disporre un manifesto con firma digitale che consente di firma l'applicazione nella gerarchia RMS di Active Directory. Il manifesto definisce tali moduli che possono e non possono essere caricato nello spazio degli indirizzi dell'applicazione per creare un ambiente protetto e proteggere il contenuto non crittografato in memoria. Per un manifesto per essere valido, deve essere firmato digitalmente da un'autorità di certificazione (CA) appartenente a una gerarchia di certificati RMS di Active Directory. Può trattarsi di gerarchia della produzione con una CA di firma applicazione controllata in modo esclusivo da Microsoft, oppure può essere la gerarchia di preproduzione che consente agli sviluppatori di self-sign applicazione manifesti. Si noti che un manifesto può appartenere a una gerarchia, ma non entrambi. Un manifesto firmato da un'autorità di CERTIFICAZIONE di produzione è non valido nella gerarchia di preproduzione e viceversa perché le gerarchie dispone di autorità principale diverso. Manifesti dell'applicazione vengono descritti in dettaglio il SDK DI RMS DI ACTIVE DIRECTORY.
Quando si installa il primo server RMS di Active Directory in un insieme di strutture di Active Directory, in modo implicito è stabilire la gerarchia RMS di Active Directory. Per impostazione predefinita, la routine di installazione RMS di Active Directory utilizza una CA di Microsoft DRM server registrazione libero per emettere il server Licensor certificato (SLC), che fa parte della gerarchia che comporta la radice di produzione Microsoft DRM nella directory principale dell'attendibilità. Nella figura 1 viene illustrata questa catena di certificazione, derivata da SLC di una produzione server RMS di Active Directory. Si desidera esaminare la gerarchia RMS di Active Directory nel proprio ambiente, consultare il materiale di accompagnamento, che include lo strumento di catena di certificati RMS di Active Directory (CertificateChain.exe).
Figura 1 l'Active Directory RMS applicazione firma Certifi cate a cui appartiene la gerarchia di preproduzione RMS di Active Directory.
Directory principale di produzione Microsoft DRM stabilisce la gerarchia della produzione e Microsoft richiede tutti i fornitori di software firmare un contratto di licenza produzione come prerequisito per ottenere un certificato di produzione e firma le applicazioni in gerarchia della produzione. Lo scopo del certificato di produzione è per creare e firmare i manifesti delle applicazioni rilasciate. Per scopi di sviluppo, viene invece utilizzato un certificato di preproduzione. Inizialmente, fornitori di software firmare un contratto di licenza sviluppo per ottenere un certificato di preproduzione anche obbligatori Microsoft, ma una chiave pubblica (ISVTier5AppSIgningPubKey.dat), la chiave privata (ISVTier5AppSigningPrivKey.dat) e il certificato di preproduzione corrispondente (ISVTier5AppSignSDK_Client.xml) ora è incluso NELL'SDK di RMS di Active Directory in modo che è possibile firmare i manifesti durante la fase di sviluppo senza dover contattare Microsoft. Come una nota di lato, le chiavi e certificati di preproduzione sono inoltre inclusi nel protezioni con formato file di Microsoft Office origine codice pacchetto.
Firma un manifesto dell'applicazione utilizzando il certificato di preproduzione implica che non è possibile utilizzare l'applicazione in combinazione con un server di produzione RMS di Active Directory. Figura 1 Mostra, l'autorità emittente principale nella catena di certificati di isvtier5appsignsdk_client.xml è Microsoft DRM ISV principale che ovviamente non è la radice di un server di produzione. È possibile esaminare isvtier5appsignsdk_client.xml utilizzando strumento il catena di certificati RMS di Active Directory. Ne consegue che è necessario un server RMS di Active Directory con un diverso SLC contenente la directory principale ai fornitori di software INDIPENDENTI di Microsoft DRM nella directory principale dell'attendibilità (vedere la Figura 1 ). Per distribuire un server di RMS di Active Directory, è necessario stabilire un insieme di strutture di Active Directory separato per l'ambiente di sviluppo.
Topologia di preproduzione RMS di Active Directory
Con un insieme di strutture Active Directory separato, è consigliabile per fornire alcuni concetti alla topologia di preproduzione RMS di Active Directory. In particolare, è necessario decidere se installare RMS di Active Directory su un server autonomo o direttamente sul controller di dominio. Nella maggior parte dei casi, una distribuzione di controller di dominio è sufficiente per scopi di sviluppo. Si noti che questo non è un'indicazione per gli ambienti di produzione. In un ambiente di produzione, è necessario distribuire non RMS di Active Directory su un controller di dominio poiché l'account utente di dominio che è impostato come identità di rete RMS di Active Directory viene quindi richiede autorizzazioni di amministratore di dominio di accesso locale. Accesso locale è un privilegio di amministratore nei controller di dominio. In un server membro, l'account utente del dominio non è necessario autorizzazioni elevate affatto. In caso di dubbi sulla domanda di controller di dominio in ambienti di produzione, leggere articolo di blog Jason Tyler" Il DOs e DON'Ts di RMS." Viene sull'idea di inserimento RMS su un controller di dominio, Jason visualizzato, "tratta tali una cattiva idea, che ogni volta che viene visualizzata, desidera passare indicare la persona per selezionare un'opzione e soddisfare mi dietro il toolshed".
La domanda successiva è se installare WSS 3.0, Office 2007 e Visual Studio 2008 sul controller di dominio. Qui si deve utilizzare un server separato, in modo definito anche in un ambiente di sviluppo. Come per il problema RMS di Active Directory, la configurazione di protezione di WSS 3.0 differisce nei controller di dominio in confronto con i server membri. Utilizzando un server membro, è possibile mantenere una configurazione paragonabile a un ambiente di produzione WSS 3.0, fornisce risultati più affidabili quando test compilato componenti. Naturalmente, è possibile mantenere il controller di dominio e server membro su un singolo computer fisico se si utilizza Microsoft V Hyper Server 2008, come illustrato nella Figura 2 . V Hyper è tecnologia di virtualizzazione 64 bit, si può essere utilizzata versione x 64 di Windows Server 2008 su entrambi i computer virtuale. Si noti che V Hyper Server 2008 non include gli strumenti di gestione grafica, ma è possibile installare V Hyper server remoto Management Tools su una workstation Windows Vista separata, come descritto in un foglio di lavoro complementare relativa installazione V Hyper server alla remota gestione su una workstation di Windows Vista.
Nella figura 2 A small-scale RMS di Active Directory ambiente di sviluppo in un host. Hyper-V
Configurazione di server preproduzione
Prima di installare il ruolo di Active Directory Rights Management Services, è necessario configurare alcune impostazioni del Registro di sistema sul server in modo che consente di registrarsi per l'installazione di Active Directory RMS utilizzare il server della gerarchia di preproduzione. Se si ignora questo passaggio di configurazione, verrà terminare i con la gerarchia non valido. Tenere presente che non è possibile spostare un server RMS di Active Directory tra gerarchie. Se il server è registrato nella gerarchia della produzione, è necessario disinstallare RMS di Active Directory, eliminare il punto di connessione di servizio (SCP) RMS di Active Directory in Active Directory, configurare il Registro di sistema e quindi installare di nuovo il ruolo di Active Directory Rights Management Services.
Nella figura 3 Elenca l'impostazione del Registro di sistema che determina la gerarchia RMS di Active Directory su un computer che esegue Windows Server 2008. L'impostazione del parametro gerarchia su 1 consente la gerarchia di preproduzione. Un valore pari a 0 oppure dall'assenza di questo parametro indica che nella gerarchia della produzione consigliabile distribuire RMS di Active Directory. Impostazioni del Registro di sistema aggiuntive esistono per garantire la compatibilità con le versioni precedenti, ma questo non è un requisito di nostro ambiente di sviluppo. Per ulteriori informazioni, vedere l'argomento "registro di configurazione sistema" NELL'SDK di RMS di Active Directory. Il codice riportato di seguito può essere salvato come file del Registro di sistema (con estensione reg) per attivare la gerarchia di preproduzione su un server RMS di Active Directory.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DRMS\2.0]
"Hierarchy"=dword:00000001
Nella figura 3 il client RMS di Active Directory can’t accedere al server di RMS di Active Directory.
Problemi relativi alla configurazione IRM di SharePoint
La distribuzione server RMS di Active Directory e la configurazione è relativamente uncomplicated. Trickier è la configurazione del server membro che esegue WSS 3.0 per firmare SharePoint nella gerarchia di preproduzione. È Impossibile solo avviare Amministrazione centrale SharePoint 3.0, consente di passare alla scheda operazioni fare clic sul servizio Information Rights Management e quindi selezionare l'opzione utilizza il server RMS predefinito specificato in Active Directory. Fare clic su OK produrrebbe solo il messaggio di errore visualizzato nella Figura 3 . Come rivela il messaggio, il client RMS di Active Directory (msdrm.dll) è presente, viene installato con Windows Server 2008 per impostazione predefinita, ma il server RMS di Active Directory non è accessibile.
Sfortunatamente, messaggio di errore, né log di traccia, né registro eventi applicazioni rivelare la true natura del problema. Uno per ottenere informazioni più dettagliate consiste nell'accedere ALL'URL specificato nel registro traccia direttamente in Internet Explorer, ad esempio https://adrms.litware.com:443/\_wmcs/certification. Molto probabilmente verrà segnala un "problema con il certificato di protezione del sito Web" se il server RMS di Active Directory preproduzione utilizza un certificato di layer (SSL) autofirmato secure sockets che il client non attendibile. Considerare attendibile il certificato del server SSL, è necessario installare il certificato SSL nell'archivio Autorità di certificazione principale attendibili nel computer locale. Assicurarsi che inserire il certificato nell'archivio fisico del computer locale perché il certificato deve eseguire disponibili per tutti i conti protezione SharePoint, non solo proprio account utente. Foglio di lavoro correlata distribuzione WSS01 in ambiente di preproduzione RMS Active Directory vengono descritti i passaggi.
In alcuni casi, potrebbe essere difficile gestire i certificati SSL autofirmati. SharePoint determina l'URL del servizio Web certificazione di RMS di Active Directory per mezzo del SCP RMS di Active Directory in Active Directory. Se tale SCP specifica un URL con un nome host è diverso dal nome host nel certificato SSL del server Web, il server Web non rimane attendibile anche dopo aver installato il certificato SSL nell'archivio Autorità di certificazione principale attendibili. Nella figura 4 è illustrato uno scenario comune di configurazione che conduce a questo problema. La configurazione utilizza un alias NELL'URL di RMS di Active Directory è diverso dal nome host effettivo. Questo semplifica server manutenzione ripristino d'emergenza perché non è possibile modificare l'URL di RMS di Active Directory dopo la distribuzione di un server RMS di Active Directory, ma il record CNAME consente di posizionare l'URL di un altro server se necessario. Come indicano i quattro passaggi nella Figura 4 , in primo luogo, il server SharePoint Cerca l'attributo serviceBindingInformation del SCP RMS di Active Directory per determinare l'URL di RMS di Active Directory. Successivamente, risolve il adrms.litware.com nome host dc01.litware.com in base al record CNAME. SharePoint si connette quindi dc01.litware.com, che restituisce il certificato SSL per dc01.litware.com, e in questo modo il conflitto di indirizzi non corrispondenti.
Nella figura 4 SSL il certificato è non attendibile a causa di una mancata corrispondenza del nome.
Per risolvere il conflitto, emettere un certificato SSL per adrms.litware.com sul server RMS di Active Directory utilizzando lo strumento SelfSSL disponibile in Internet Information Services (IIS) 6.0 Resource Kit. Foglio di lavoro correlata distribuzione DC01 in ambiente di preproduzione RMS Active Directory include download informazioni e istruzioni dettagliate.
Correzione SSL problemi di certificato è il primo passaggio verso una configurazione funzionante, ma un certificato SSL attendibile non è l'unico requisito. Se si tenta di configurare IRM senza concedere prima l'account di protezione di Amministrazione centrale pool di applicazioni lettura ed esecuzione di accesso, riceverai il messaggio di errore che IRM non funzionerà fino a quando il server concede l'autorizzazione. Nome dell'account di dominio utilizzato: WSS01$@litware.com. Questo errore viene visualizzato perché il client deve chiamare il metodo di Certify del servizio di Web certificazione RMS di Active Directory per ottenere un autorizzazioni account certificato (RAC), che si verifica un errore due to autorizzazioni di accesso mancante nel file ServerCertification.asmx. Per impostazione predefinita, solo account di sistema del server RMS di Active Directory dispone di accesso. La soluzione consigliata consiste nel ereditare autorizzazioni dalla cartella certificazione sul ServerCertification.asmx e quindi aggiungere gli account computer del server WSS 3.0 con lettura ed esecuzione as well autorizzazioni. Questo garantisce che tutti gli account potenziale del pool di applicazione dispongano di autorizzazioni richiesti. Prospetto complementare distribuzione DC01 in ambiente di preproduzione RMS Active Directory per ulteriori informazioni, vedere.
Problemi specifici di preproduzione
A questo punto, il framework IRM dovrà essere funzionale, tranne quando sono in un ambiente di preproduzione. Tenere presente che client RMS di Active Directory e le applicazioni devono utilizzare una catena di certificati differenti qui. Se si prova configurare il framework IRM nella configurazione originale, verrà visualizzato l'errore "il necessari Windows Rights Management client è presente ma non può essere configurato correttamente" e nel log dell'analisi include un altro suggerimento utile "il computer è non stato attivato." Questo è un indicatore il cui il client RMS di Active Directory è ancora nella gerarchia della produzione. È possibile verificare questo editor del Registro di sistema. Controllare le chiavi del Registro di sistema HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\uDRM\Hierarchy e HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\uDRM\Hierarchy. Un valore pari a 0 indica la gerarchia della produzione. Modifica i valori su 1 consente di attivare la gerarchia di preproduzione. Il codice riportato di seguito sono elencati un file .reg per applicare opportunamente le modifiche di configurazione.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\uDRM]
"Hierarchy"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\uDRM]
"Hierarchy"=dword:00000001
Tuttavia, non essere sorpresa che le modifiche del Registro di sistema non effettive immediatamente. L'errore rimane poiché il client RMS di Active Directory è già stato generato un certificato di computer non corretto durante il primo tentativo non riuscito e continua a utilizzare il certificato. Sul server WSS, aprire la cartella C:\ProgramData\Microsoft\DRM\Server ed eliminare tutte le sottocartelle e file. È inoltre possibile controllare la cartella %LOCALAPPDATA%\Microsoft. Se questo comprende una sottocartella \DRM, eliminare la sottocartella in quanto memorizza licenze client che non sono utilizzabili più nella gerarchia di preproduzione. Il client RMS di Active Directory ricrea tali sottocartelle e il file di certificato in esse necessarie.
Passare nuovamente a Amministrazione centrale SharePoint 3.0, provare nuovamente a configurare IRM e non consentire il successivo messaggio di errore è fool: È lo stesso messaggio di errore come prima ma il motivo dell'errore è effettivamente diverso. Controllo che il log di traccia e si sono disponibili che "si è verificato un problema durante la creazione e l'inizializzazione di una protezione Environment…" Ora si tratta di un problema di manifesto. SharePoint utilizza comunque il manifesto di produzione come l'rivela lo strumento di catena di certificati RMS di Active Directory se si apre il file Stsprtid.xml nella cartella %PROGRAMFILES%\Common comuni\Microsoft Shared\Web Server Extensions\12\Bin (vedere la Figura 5 ).
Nella figura 5 doesn’t lavoro il manifesto di produzione nella gerarchia di preproduzione.
È necessario eliminare (o rinominare) la produzione Stsprtid.xml file, generare un nuovo manifesto utilizzando lo strumento Genmanifest.exe includere in SDK RMS Active Directory nonché come nel pacchetto di download di protezioni con formato file di Microsoft Office e quindi riavviare IIS. Il pacchetto di download è dotato anche di un file di configurazione di SharePoint (sharepoint.mcf) e file batch (genmft.bat e genmft.64.bat) per semplificare questa attività. Tuttavia, il file batch per gli ambienti a 64-bit solo firma di applicazioni di Microsoft Office nella gerarchia di preproduzione e Ignora SharePoint. Per accedere in SharePoint in un server a 64-bit, utilizzare il file di Sharepoint.bat includere nel materiale di complementare oppure utilizzare lo strumento di Genmanifest.exe direttamente. La sintassi del comando è la seguente
Genmanifest.exe -chain isvtier5appsignsdk_client.xml sharepoint.mcf
Stsprtid.xml
Vedere anche pagina Genmanifest.exe aspx msdn.microsoft.com/en-us/library/aa362621 (VS.85).
Compilazione e registrazione
Con sostituito nel file manifesto di SharePoint, è possibile completare correttamente la configurazione di IRM. La parte difficile è terminata. Ora è tempo di perdere i premi compilazione e verifica i componenti di protezione. Si tratta di un semplice portata. Il codice sorgente proviene con i progetti di Visual Studio 2005 è possibile aggiornare a Visual Studio 2008 senza problemi. Tuttavia, tenere presente che sta utilizzando un server a 64 bit. I progetti di Visual Studio sono configurati per un ambiente a 32 bit. È necessario modificare la configurazione per compilare i componenti per la piattaforma x 64, come illustrato nella Figura 6 . Vedere anche il foglio di lavoro correlata "Compiling, test and protezioni con formato file di distribuzione Microsoft Office".
Nella figura 6 per utilizzare programmi di protezione su un server WSS 64-bit IRM, compilare il codice sorgente per la piattaforma x 64.
Visual Studio si occupa della registrazione del componente COM in fase di generazione, ma è comunque necessario registrare programmi di protezione IRM in WSS 3.0. Registrare i componenti con i relativi identificatori di classe (CLSID) in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\IrmProtectors. Qui è un file di registro di sistema che esegue questo passaggio:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server
Extensions\12.0\IrmProtectors]
"{2E4402B2-F2DA-4BC8-BB2C-41BECF0BDDDB}"="MsoIrmProtector"
"{81273702-956F-4CBD-9B16-43790558EE29}"="OpcIrmProtector"
È inoltre possibile verificare il contenuto del file IrmProtectors.reg nel materiale di accompagnamento. Contiene ulteriori chiavi per scopi informativi. Queste chiavi È incluso perché i programmi di protezione di MOSS 2007 IRM dispone di voci simili. L'unica differenza è che protezioni con MOSS utilizzano effettivamente le impostazioni mentre il protezioni con IRM utilizzano invece valori hardcoded.
IRM Protector test
Una volta che WSS è di programmi di protezione IRM, è possibile riavviare IIS, aprire il sito di SharePoint, configurare un criterio RMS di Active Directory per una raccolta documenti, creare, caricare e quindi download di documenti per verificare che funzionino programmi di protezione IRM. Tuttavia, questa può richiedere molto tempo se sono ancora problemi di registrazione COM base. Ad esempio, se dimenticato attivare x 64 - bit piattaforma di Visual Studio, il processo di compilazione viene completata senza errori ma la registrazione COM rimane incompleta, WSS Impossibile caricare le protezioni con e non sarà in grado di verificare la protezione RMS di Active Directory. È possibile risparmiare tempo verifica innanzitutto la registrazione COM ed eseguendo il test in SharePoint solo se il controllo di registrazione Visualizza successo completata. Nella figura 7 è illustrato uno script base per controllare la registrazione COM. Semplicemente carica i componenti COM e visualizza una finestra di messaggio con i risultati.
On Error Resume Next
set MsoIrmProtector=NOTHING
set OpcIrmProtector=NOTHING
set MsoIrmProtector=CreateObject("MsoIrmProtector.MsoIrmProtector")
set OpcIrmProtector=CreateObject("OpcIrmProtector.OpcIrmProtector")
IF MsoIrmProtector IS NOTHING AND OpcIrmProtector IS NOTHING THEN
Wscript.Echo "Unable to load MsoIrmProtector and OpcIrmProtector."
ELSEIF MsoIrmProtector IS NOTHING THEN
Wscript.Echo "OpcIrmProtector loaded successfully, but
unable to load MsoIrmProtector."
ELSEIF OpcIrmProtector IS NOTHING THEN
Wscript.Echo "MsoIrmProtector loaded successfully, but
unable to load OpcIrmProtector."
ELSE
Wscript.Echo "MsoIrmProtector and OpcIrmProtector loaded
successfully."
END IF
Le protezioni nella figura 7 Creazione che IRM con correttamente sono registrati come componenti COM prima di testare le protezioni con in SharePoint.
On Error Resume Next
set MsoIrmProtector=NOTHING
set OpcIrmProtector=NOTHING
set MsoIrmProtector=CreateObject("MsoIrmProtector.MsoIrmProtector")
set OpcIrmProtector=CreateObject("OpcIrmProtector.OpcIrmProtector")
IF MsoIrmProtector IS NOTHING AND OpcIrmProtector IS NOTHING THEN
Wscript.Echo "Unable to load MsoIrmProtector and OpcIrmProtector."
ELSEIF MsoIrmProtector IS NOTHING THEN
Wscript.Echo "OpcIrmProtector loaded successfully, but
unable to load MsoIrmProtector."
ELSEIF OpcIrmProtector IS NOTHING THEN
Wscript.Echo "MsoIrmProtector loaded successfully, but
unable to load OpcIrmProtector."
ELSE
Wscript.Echo "MsoIrmProtector and OpcIrmProtector loaded
successfully."
END IF
Con impostazioni di registrazione appropriato, il componente OpcIrmProtector per formati di documenti di Office 2007 è immediatamente funzionante. Il componente MsoIrmProtector per formati precedenti di Office dispone tuttavia di un requisito aggiuntivo. La cartella che contiene il MsoIrmProtector.dll deve contenere una sottocartella \1033 anche con i file di modello. I file di modello forniti con il codice sorgente e trovano nella cartella \MsoIrmProtector\Templates. È necessario copiare i file nella sottocartella \1033 in modo che il componente MsoIrmProtector possibile includerli nei documenti RMS–protected Active Directory per la compatibilità con applicazioni di Office che non supportano RMS di Active Directory, ad esempio Office 2000 e Office XP. In caso contrario, non sarà in grado di aprire documenti di Office precedenti. Ad esempio, verrà visualizzato l'errore visualizzato nella Figura 8 quando si tenta di creare un nuovo documento di Word in una raccolta documenti.
Nella figura 8 che Word can’t leggere il documento perché il MsoIrmProtector non è creare il documento nel formato corretto senza i file di modello in grado di .
Distribuzione personalizzata protezioni con documenti IRM
Congratulazioni. Avere correttamente incorporato, registrato e testato personalizzato protezioni con IRM per WSS 3.0. A questo punto, come si ottengono questi componenti su server di produzione di WSS 3.0? Dopo tutto, è necessario installare programmi di protezione IRM su tutti i server se si desidera utilizzare questi componenti nell'ambiente di produzione. Eseguire manualmente la distribuzione sarà noioso e soggetto a errori. È preferibile generare un progetto di installazione, includere le DLL e i documenti di modello all'interno della struttura del file richiesto, importare le impostazioni del Registro di sistema necessari per integrare i componenti NELL'WSS 3.0 e quindi utilizzare il file di Microsoft Windows Installer (MSI) risultante per la distribuzione.
È anche un consigliabile per verificare la distribuzione in un sistema di riferimento. Tra le altre cose, tali test rivela importanti prerequisiti che devono essere soddisfatti prima di distribuire i componenti. In particolare, Visual Studio 2008 aggiunge le dipendenze di Microsoft .NET Framework 3.5 SP1 al programma di installazione e i componenti della protezione richiedono un package ridistribuibile di Microsoft Visual c ++. Questo è un requisito standard per file eseguibili e DLL compilata con Visual c ++. Verificare che il package ridistribuibile corrisponda alla versione che si utilizza nell'ambiente di sviluppo. Ad esempio, se si utilizza Microsoft Visual Studio 2008 SP1, quindi distribuire Microsoft Visual c ++ 2008 SP1 Redistributable Package (x 64). Il foglio di lavoro complementare "test di Microsoft Office file formato protezioni con distribuzione" viene illustrato come verificare la distribuzione di protezione IRM in un singolo server.
Conclusione
Protezione con tecnologie IRM dei documenti di Microsoft Office utilizzato per richiedere MOSS 2007, ma compilando le protezioni con formato file di Microsoft Office codice sorgente disponibile nella raccolta di codice di MSDN è possibile integrare i componenti di protezione IRM appropriati in WSS 3.0 nonché. È inoltre possibile modificare il codice sorgente per implementare funzionalità personalizzate se si dispone delle competenze C o c ++ e hanno distribuito SharePoint in un ambiente di preproduzione RMS di Active Directory. Tenere presente che le modifiche interessare tutte le raccolte di documenti RMS–enabled Active Directory. SI consiglia di lasciare il codice sorgente non modificato e il controllo della raccolta di codice MSDN regolarmente per aggiornamenti e forse nuove versioni con funzionalità aggiuntive, a meno che non si uno sviluppatore di cercare un ottimo esempio di integrare le applicazioni con il framework IRM. In questo caso, il codice di origine è un eccellente punto di partenza.
Tenere presente che Microsoft non progettare il framework IRM per proteggere elementi contenuti in database SharePoint. Ad esempio, è consigliabile non modificare le routine di decrittografia o gli utenti di SharePoint potrebbero non essere possibile aprire i documenti perché il framework IRM concede solo l'account del pool di applicazioni e l'utente corrente autorizzazioni di accesso RMS di Active Directory quando si protegge il contenuto. Tenere inoltre presente che alcuni programmi di protezione richiede altri programmi di protezione creare un sistema completamente funzionale. Ad esempio, la protezione MsoIrmProtector per formati di documento di Office precedenti e la protezione OpcIrmProtector per i formati di Office 2007 appartengono insieme. Se è distribuita le protezioni con MsoIrmProtector senza il OpcIrmProtector, un utente di Word 2007 potrebbe creare un nuovo documento utilizzando il modello di contenuto template.doc in SharePoint, durante il salvataggio del file come Doc1.docx. Le protezioni con MsoIrmProtector all'protezione RMS di Active Directory template.doc, Doc1.docx sarebbe costretti nella raccolta documenti nel modulo protetto da diritti perché esiste nessuna protezione OpcIrmProtector per decrittografare il contenuto al momento del caricamento. L'account del pool di applicazioni e l'utente corrente potrebbe rimangono le entità sola possono aprire il documento. Esistono altri modi per proteggere documenti nel database del contenuto SharePoint tramite RMS di Active Directory, ad esempio tramite l'interfaccia COM ISPExternalBinaryStorage.
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.