All'interno di SharePoint Creazione di una soluzione di archiviazione esterno per SharePoint

Pav Cherny

Download codice disponibile in: ChernySharePoint2009_06.exe(2,006 KB)

Contenuto

Archiviazione binario interno
Archiviazione binario esterno
Creazione un provider EBS non gestito
Creazione un provider EBS gestito
Registrazione di un provider EBS in SharePoint
Implementazione di Garbage Collection
Conclusione

Microsoft stima che quanto 80 % dei dati memorizzati in Microsoft Windows SharePoint Services (WSS) 3.0 e Microsoft Office SharePoint Server (MOSS) 2007 database del contenuto è dati non relazionali grande oggetto binario di (BLOB), ad esempio documenti, fogli di calcolo di Microsoft Office Excel e presentazioni di Microsoft Office PowerPoint di Microsoft Office Word. Solo il 20 percento è relazionali metadati, che implica un utilizzo suboptimal delle risorse di Microsoft SQL Server al database back-end. SharePoint non sfrutta di recenti innovazioni di SQL Server per i dati non strutturati introdotte in SQL Server 2008, ad esempio il FILESTREAM attributo o API di archiviazione BLOB remoto, ma fornisce il proprio le opzioni per aumentare l'efficienza di archiviazione e la facilità di gestione dei volumi di dati rilevanti.

In particolare, SharePoint include un provider di archiviazione esterne binario API, ISPExternalBinaryProvider, che Microsoft prima pubblicata come un hotfix in maggio 2007 e incorporare più avanti nel Service Pack 1. L'API ISPExternalBinaryProvider è separata DALL'API di archiviazione BLOB remoto. Tramite fornitori terzi possono utilizzare l'API per integrare SharePoint con soluzioni di archiviazione avanzate, ad esempio sistemi di archiviazione indirizzabili contenuto (CAS). È inoltre possibile utilizzare questa API per mantenere i dati di SharePoint BLOB su un server centrale file all'esterno di database del contenuto Se si desidera creare una soluzione personalizzata per aumentare l'efficienza di archiviazione e la scalabilità di una farm SharePoint. Tenere presente, tuttavia, che questa API è specifica per WSS 3.0 e MOSS 2007. Verrà modificata nella prossima versione SharePoint, che significa che sarà necessario aggiornare il provider.

In questo articolo illustrato come estendere l'architettura di archiviazione SharePoint utilizzando l'API ISPExternalBinaryProvider, inclusi vantaggi e svantaggi, i dettagli di implementazione, alcune considerazioni sulle prestazioni e la procedura di garbage collection. Inoltre discutere di compatibilità a 64-bit problema di Microsoft Visual Studio che possono causare SharePoint eseguire il caricamento gestito componenti ISPExternalBinaryProvider Nonostante un'implementazione dell'interfaccia corretta. Se necessario, è possibile consultare la documentazione ISPExternalBinaryProvider in WSS 3.0 SDK. Un altro riferimento opportuno accennando è Blog Kyle Tillman.

Kyle è un processo grande spiegare come ha gestiti ostacoli l'implementazione nel codice gestito, ma non WSS 3.0 SDK né del Kyle post del blog include un progetto di esempio di Visual Studio, pertanto HO deciso di campioni ISPExternalBinaryProvider nel codice sia non gestito e gestite in correlata materiale questa colonna. Lo scopo di questi esempi è che consentono di iniziare se desidera l'integrazione di soluzioni di archiviazione esterne con SharePoint. Tenere presente, tuttavia, che questi esempi sono e non è pronto per l'utilizzo di produzione.

Archiviazione binario interno

Per impostazione predefinita, SharePoint memorizzate dati BLOB nella colonna contenuta della tabella AllDocStreams il database del contenuto. Il vantaggio evidente di questo approccio è semplice transazionale coerenza tra i dati relazionali e il contenuto del file non relazionali associato. Ad esempio, non è complicato per inserire i metadati di un documento di Word insieme con il contenuto non strutturato in un database del contenuto neppure è complicato per associare il contenuto non strutturato corrispondente di aggiornamento della seleziona, i metadati o eliminare operazioni. Tuttavia, lo svantaggio più ovvia dell'approccio predefinito è un utilizzo inefficiente delle risorse di archiviazione. Nonostante un sottosistema di I/O ottimizzato per ad alte prestazioni, il motore di archiviazione SQL Server non è esattamente è una sostituzione dei file server.

Un database di SQL Server è costituito registro delle transazioni e dati i file, come illustrato nella Figura 1 . Per assicurare il funzionamento transazionale affidabile, SQL Server prima scrive tutti i record delle transazioni nel file di registro prima Svuota i dati corrispondenti in pagine 8KB il file di dati sul disco. In base al modello di ripristino selezionato, questo metodo richiede più di due volte la dimensione BLOB nella capacità di archiviazione fino a eseguire un backup e cancellare il log delle transazioni. Inoltre, SQL Server non memorizza non strutturato contenuto di SharePoint direttamente in pagine di dati. Al contrario, SQL Server utilizza un insieme separato di pagine text o image e memorizza solo un puntatore di testo a 16 byte a nodo principale al BLOB nella riga di dati. Text/Image pagine sono organizzate in una struttura balanced, ma vi è un solo insieme di pagine text o image per ogni tabella. Per la tabella AllDocStreams, ciò significa che il contenuto di tutti i file verrà ripartito tra lo stesso insieme pagina text o image. Una pagina di solo testo e immagine può contenere frammenti di dati da più BLOB oppure possono tenere nodi intermedi per BLOB maggiore 32KB nella dimensione.

Figura 1 archiviazione BLOB di SharePoint predefinito in SQL Server

Non si accedere troppo profondamente in elementi interni di SQL Server, anche se. Il punto è che quando la lettura di contenuto non strutturato, SQL Server deve passare attraverso la riga di dati per ottenere il puntatore di testo e quindi tramite nodo principale e probabilmente altri nodi intermedi per individuare tutti i dati al BLOB frammenti distribuito tra qualsiasi numero di pagine text o image che SQL Server deve caricare nella memoria in completo per ottenere tutti i blocchi di dati. Si tratta in quanto SQL Server esegue operazioni di I/O a livello di pagina. Queste complessità ripercussioni sulla prestazioni di flusso-file rispetto a accesso diretto attraverso il sistema di file. SQL Server impone un limite di dimensione del disco rigido di 2 GB su SharePoint anche perché è la capacità massima del tipo di dati immagine. La colonna di contenuto della tabella AllDocStreams è una colonna image in modo che non può memorizzare file maggiori di 2 GB in un database del contenuto di SharePoint.

Archiviazione binario esterno

L'API ISPExternalBinaryProvider offre un'alternativa intelligenti all'interno archiviazione BLOB nel database del contenuto SharePoint. È una semplice interfaccia COM con solo due metodi (StoreBinary e RetrieveBinary), utilizzabile per implementare un provider di archiviazione binario esterni (EBS). Per informazioni dettagliate di architettura, vedere l'argomento" Architettura di archiviazione BLOB esterno"in SDK 3.0 WSS.

SharePoint carica il provider EBS quando si imposta la proprietà ExternalBinaryStoreClassId dell'oggetto SPFarm locale (SPFarm.Local.ExternalBinaryStoreClassId) all'identificatore della classe COM del provider (CLSID). SharePoint chiama StoreBinary metodo il provider ogni volta che è inviare dati BLOB, ad esempio quando si sta caricando un file in una raccolta documenti. Il provider EBS possibile decidere di memorizzare il BLOB in relativo sistema di archiviazione esterno associato e restituire un identificatore BLOB corrispondente (ID BLOB) in SharePoint, o è possibile impostare il parametro pfAccepted nel metodo StoreBinary su false per indicare che non gestire al BLOB. In quest'ultimo caso, SharePoint memorizzate al BLOB nel database del contenuto come di consueto. Al contrario, se il provider EBS accettati al BLOB, SharePoint inserisce soltanto l'ID del BLOB nella colonna della tabella AllDocStreams contenuta come indicato nella Figura 2 . L'ID del BLOB può essere qualsiasi valore che consente il provider EBS per individuare il il contenuto nel sistema di archiviazione esterne, ad esempio un nome di file, un percorso di file, un identificatore univoco globale (GUID) o un digest del contenuto. GUID provider di esempio inclusi nel materiale di accompagnamento, ad esempio utilizzare come nomi di file per l'identificazione affidabile del blob in un file server.

Nella figura 2 la memorizzazione di un BLOB di SharePoint in un sistema di archiviazione esterna

SharePoint inoltre tiene traccia dei file archiviati esternamente impostando il bit DocFlags più alto di questi file su 1. DocFlags è una colonna della tabella AllDocs. Quando un utente richiede di scaricare un file memorizzato esternamente, SharePoint verifica DocFlags e passa il valore contenuto dalla tabella AllDocStreams al metodo RetrieveBinary del provider EBS. In risposta alla chiamata RetrieveBinary, il provider EBS deve recuperare BLOB indicato dal sistema di archiviazione esterno e tornare del contenuto binario SharePoint di un oggetto COM che implementa l'interfaccia ILockBytes. Si noti che SharePoint non è a chiamare il metodo RetrieveBinary per BLOB memorizzati direttamente nel database di contenuto.

Si noti inoltre che i processi di archiviazione e recupero trasparente per l'utente, purché l'utente non tenta di ignorare SharePoint. Pertanto, non è necessario sostituire incorporata di Web part con le versioni personalizzate che metadati equivalenti in un elenco con un documento memorizzato esternamente; le applicazioni di produttività, ad esempio Microsoft Office non necessario sapere come archiviare i metadati in un'unica posizione e quindi il documento in un altro; e ricerca non è necessario elaborare separato dai documenti di metadati. Inoltre e questo è uno dei vantaggi Preferiti dell'architettura del provider EBS, l'utente deve passare attraverso SharePoint per accedere ai esternamente memorizzati dati BLOB. Un utente esclusione di SharePoint e accede direttamente a un database contenuto tramite una connessione di SQL Server termina i download ID BLOB invece del contenuto di file effettivo, come illustrato nella Figura 3 . È possibile verificare questo comportamento se si distribuisce la SQL download Web part (che utilizzato nella colonna 2009 aprile per illustrare come ignorare protezione RMS di Active Directory di SharePoint) in un ambiente di prova. Inoltre, gli utenti non devono e non deve dispone, autorizzazioni di accesso all'archivio BLOB esterno. Solo gli account di protezione di SharePoint richiedono l'accesso poiché SharePoint chiama i metodi di provider EBS nel contesto di protezione di account del pool di applicazioni del sito.

Nella figura 3 EBS il provider può essere un roadblock per ignorare autorizzazioni di SharePoint per i download di file

Tenere presente, tuttavia, che provider EBS dispongano svantaggi a causa della complessità della gestione integrità tra metadati nel database del contenuto della farm di SharePoint e l'archivio BLOB esterno. Per informazioni buona e relativi vantaggi e svantaggi, vedere l'argomento" Limiti operativi e analisi Trade-Off"in SDK 3.0 WSS. Assicurarsi di che leggere questo argomento molto importante prima di implementare un provider EBS in un ambiente SharePoint.

Creazione un provider EBS non gestito

Ora Affrontiamo i problemi di creazione di provider EBS. L'interfaccia ISPExternalBinaryProvider è ben documentato in WSS 3.0 SDK in" L'interfaccia di accesso BLOB: ISPExternalBinaryProvider." Tuttavia, sembra che Microsoft dimenticato coprire i dettagli di provider EBS. Dopo tutto, non si solo utilizzano l'interfaccia di un server COM esistente. Si sono compiti con creazione il server COM di lavoro e implementa l'interfaccia ISPExternalBinaryProvider. Ma soprattutto, WSS 3.0 SDK non riesce a citare il tipo di server COM che è si suppone di creare e il modello di threading necessario. Un server COM classico può eseguire out-of-processo o in-process e può supportare il modello di apartment a thread singolo (STA, Single-Threaded APARTMENT), il modello di apartment con multithreading (MTA) o entrambi, o il modello a thread libero. Per il provider EBS per il corretto funzionamento, assicurarsi che si crea un thread-safe COM server in-process che supporta il modello di threading "entrambi" per che e l'agente di trasferimento messaggi.

È inoltre necessario considerare la lingua di programmazione da utilizzare. Questo aspetto è importante perché l'interfaccia ISPExternalBinaryProvider è l'API di livello più basso di SharePoint. Problemi di prestazioni possono influire sulla intera farm di SharePoint. Per questo motivo, consiglia di utilizzando un linguaggio che consente di generare piccolo e veloce oggetti COM, ad esempio Visual c ++ e ATL (Active Template Library). ATL fornisce utili le classi c ++ per semplificare lo sviluppo di server COM indipendente dal thread nel codice non gestito con livello di supporto di threading corretto.

Visual Studio include anche numerose procedure guidate ATL. Solo creare un progetto ATL, selezionare libreria a collegamento dinamico (DLL) per il tipo di server, copia la definizione di interfaccia ISPExternalBinaryProvider di WSS 3.0 SDK nel file di lingua (IDL, INTERFACE) interfaccia di definizione del progetto ATL, aggiungere una nuova classe per un oggetto semplice ATL, selezionare "entrambi" come il modello di threading e nessuna aggregazione, quindi fare clic con il pulsante destro del mouse sulla nuova classe, scegliere Aggiungi, fare clic su Implementa interfaccia e selezionare ISPExternalBinaryProvider. Questo stato è! La Creazione guidata interfaccia implementa esegue tutti plumbing necessario, pertanto è possibile concentrarsi sull'implementazione i metodi StoreBinary e RetrieveBinary.

E non consentire intimidate è codice di c ++ non gestito. Se si analizzare il file SampleStore.cpp nel materiale di accompagnamento, è possibile verificare che le implementazioni StoreBinary e RetrieveBinary sono relativamente semplice. In pratica, il metodo di StoreBinary esempio crea un percorso di file basato su un valore del Registro di sistema StorePath, l'ID del sito passato da SharePoint e un GUID generato per il BLOB e quindi viene utilizzata la funzione Win32 WriteFile per salvare i dati binari ottenuti dall'istanza ILockBytes. Il metodo RetrieveBinary di esempio, invece, costruisce il percorso del file base lo stesso valore del Registro di sistema StorePath, l'ID del sito e l'ID del BLOB passato da SharePoint e quindi viene utilizzata la funzione ReadFile di Win32 per recuperare i dati non strutturati in modo che il provider EBS copia in una nuova istanza ILockBytes che passa quindi al SharePoint. 4 di figura viene illustrato come il provider EBS costruito il percorso del file.

Nella figura 4 creazione di percorsi di file per le operazioni StoreBinary e RetrieveBinary nei provider di esempio EBS

Creazione un provider EBS gestito

Naturalmente, gli sviluppatori preferibile utilizza familiarità linguaggi gestiti per creare provider EBS, anche se la generazione gestiti EBS provider SharePoint non è necessariamente meno complessa di creazione di provider non gestito a causa della complessità dell'interoperabilità COM. Tenere presente che un'applicazione scritta in codice non gestito solo è possibile a caricare una versione di common language runtime (CLR), in modo che il codice è necessario utilizzare la stessa versione di Common Language RUNTIME che utilizza il resto del SharePoint, in caso contrario è possibile che un un comportamento imprevisto. Inoltre, è ancora necessario gestire le interfacce non gestite e marshalling corrispondente di parametri e i buffer. Confrontare solo SampleStore.cpp con SampleStore.cs nel materiale di accompagnamento. Sono non disponibili utili utilizzando un linguaggio gestito in termini di struttura del codice o la semplicità di programmazione.

Inoltre, prendere in considerazione i problemi di compatibilità a 64-bit se si sviluppano i provider di EBS gestiti su piattaforma x 64. Figura 5 Mostra un errore comune derivante da impostazioni di registrazione COM non valide in un computer di sviluppo. Se si attiva il registro per la casella di controllo l'interoperabilità COM nelle proprietà del progetto in Visual Studio 2005 o Visual Studio 2008, verrà terminare i con impostazioni di registrazione COM per il provider nel Registro di sistema sotto HKEY_CLASSES_ROOT\Wow6432Node\CLSID\ <providerclsid>. Visual Studio utilizza la versione a 32 bit dello strumento di registrazione assembly (Regasm.exe) anche sulla piattaforma x 64.

Nella figura 5 a causa di impostazioni di registrazione COM non valide, un provider EBS gestito non è possibile caricare

Tuttavia, la versione a 64 bit di SharePoint Impossibile caricare un server COM a 32 bit registrato sotto Wow6432Node, pertanto è necessario registrare manualmente il provider EBS gestito utilizzando la versione a 64-bit Regasm.exe, che si trova nella directory %WINDIR%\Microsoft.NET\Framework64\v2.0.50727. Ad esempio, il comando "% WINDIR%\Microsoft.NET\Framework64\v2.0.50727\Regasm.exe" ManagedProvider.dll crea le impostazioni del Registro di sistema necessari per il provider di esempio gestito in HKEY_CLASSES_ROOT\CLSID\ <providerclsid>. È possibile creare un programma di installazione e contrassegnare il provider EBS per registrazione automatica COM.

Tenere presente inoltre che gestito EBS provider forniti con molte più riduzioni overhead e delle prestazioni di controparti ATL non gestiti. È possibile visualizzare questo se si confrontano le impostazioni di registrazione COM nel Registro di sistema. Come vengono chiave InProcServer32 ", verrà COM caricata DLL del provider EBS non gestita direttamente, mentre utilizzano provider EBS gestito mscoree.dll come il server di procedure, che è il modulo principale di Common Language RUNTIME. Pertanto, per i provider gestiti, il runtime COM Carica Common Language RUNTIME e quindi Common Language RUNTIME carica l'assembly provider EBS registrato sotto la chiave di assembly e crea un proxy COM Callable Wrapper (CCW) per gestire l'interazione tra il client di SharePoint non gestito (Owssvr.dll) e il provider EBS gestito.

Tenere presente che il server di SharePoint non gestito non interagisce direttamente con il provider gestito. È il CCW che esegue il marshalling dei parametri, chiama i metodi gestiti e gestisce gli HRESULT. Questo riferimento indiretto è particolarmente evidente nei tipi restituiti diversi di metodi gestiti rispetto a metodi non gestiti. I metodi non gestiti restituire HRESULT per indicare la riuscita o errori mentre si suppone di metodi gestiti per il tipo restituito void. Pertanto non restituire HRESULT esplicito in codice gestito. È necessario aumentare il sistema o eccezioni definite dall'utente in risposta a condizioni di errore. Se un metodo gestito viene completata senza un'eccezione, il CCW automaticamente restituisce S_OK se al client non gestito.

Al contrario, se un metodo gestito genera un'eccezione, il CCW associa i codici di errore e i messaggi a HRESULT e informazioni sull'errore. Il CCW implementa le interfacce di gestione degli errori diverse a tale scopo, ad esempio ISupportErrorInfo e IErrorInfo, ma SharePoint non sfrutta di queste interfacce. EBS provider deve implementare i propri segnalazione tramite il registro eventi di Windows, i registri diagnostici SharePoint, i file di traccia o altri mezzi. SharePoint prevede solo i valori HRESULT S_OK per esito positivo ed E_FAIL per qualsiasi errore. È possibile utilizzare il metodo Marshal.ThrowExceptionForHR per restituire E_FAIL in SharePoint, come illustrato Nell'SampleStore.cs.

Registrazione di un provider EBS in SharePoint

La sezione più confusione su ISPExternalBinaryProvider in WSS 3.0 SDK è facilmente l'argomento" Installazione e configurazione del provider di BLOB." Al momento di questo articolo, in questa sezione è stata inserita fuorvianti informazioni ed errori. Anche i comandi di Windows PowerShell non erano corretti. Se si assegna il provider EBS yourProviderConfig $ e successivamente utilizzare $ providerConfig.ProviderCLSID, non essere sorpresa quando si riceve un errore indicante che providerConfig $ non esiste. Naturalmente, non anche individuare questo punto poiché le proprietà attivo e ProviderCLSID non fanno parte dell'interfaccia ISPExternalBinaryProvider. Queste proprietà comprensibile appartengono a un'interfaccia duale non è illustrata nella documentazione di. Solo per ampliare ulteriormente le vostre conoscenze, È implementato una versione di esempio in codice non gestito e gestito, ma l'implementazione ISPExternalBinaryProvider non richiede queste proprietà proprietarie affatto.

La proprietà ProviderCLSID potrebbe essere utile, ma il CLSID è anche disponibile nel Registro di sistema se si cerca il ProgID, ad esempio UnmanagedProvider.SampleStore o ManagedProvider.SampleStore, è inoltre possibile trovare il CLSID nei file di codice SampleStore.rgs e SampleStore.cs. Come accennato in precedenza, impostando la proprietà ExternalBinaryStoreClassId dell'oggetto SPFarm locale sul CLSID registrato il provider EBS. Impostazione della proprietà ExternalBinaryStoreClassId dell'oggetto SPFarm locale su un GUID vuoto ("00000000-0000-0000-0000-000000000000") Rimuove la registrazione di provider EBS. Non dimenticare di chiamare metodo di aggiornamento dell'oggetto SPFarm per salvare le modifiche nel database di configurazione e riavviare Internet Information Services (IIS). Il seguente listato di codice viene illustrato come eseguire queste operazioni in Windows PowerShell:

[System.Reflection.Assembly]::LoadWithPartialName('Microsoft.SharePoint')
$farm = [Microsoft.SharePoint.Administration.SPFarm]::Local

# Registering the CLSID of an EBS provider
$farm.ExternalBinaryStoreClassId = "C4A543C2-B7DB-419F-8C79-68B8842EC005"
$farm.Update()
IISRESET

# Removing the EBS provider registration
$farm.ExternalBinaryStoreClassId = "00000000-0000-0000-0000-000000000000"
$farm.Update()
IISRESET

Implementazione di Garbage Collection

Un'altra sezione componenti comprensibile featuring WSS 3.0 SDK e frammenti di codice critiche è intitolata" Implementazione di Garbage Collection lenta." All'ora di questo articolo, in questa sezione contenuti riferimenti a un'altra classe di utilità comprensibile dei metodi DirFromSiteId e FileFromBlobid così come un'assegnazione non corretta di Directory.GetFiles risultati in una matrice FileInfo, ma non si essere troppo richiesta sulla qualità della documentazione di WSS 3.0. I metodi di supporto DirFromSiteId e FileFromBlobid rivelano lo scopo tramite i relativi nomi e la matrice FileInfo errata facilmente viene sostituita con una matrice di stringhe oppure è possibile sostituire il metodo Directory.GetFiles con una chiamata al metodo GetFiles di un oggetto DirectoryInfo. Il programma di esempio Garbage Collector nel materiale di accompagnamento utilizza l'approccio DirectoryInfo e segue la sequenza dei passaggi per la procedura di garbage collection suggerita.

Un importante deviazione del campione Garbage Collector dalle spiegazioni SDK riguarda la gestione di intervalli condizioni. Questo è un problema critico poiché possono causare condizioni intervallo misidentification e l'eliminazione di file validi durante la procedura di garbage collection. Dare un'occhiata alla Figura 6 , cui viene illustrato l'approccio di WSS 3.0 SDK–recommended per determinare il file isolati, l'enumerazione di tutti i file dell'archivio EBS BLOB e quindi rimuovere tutti i riferimenti dall'elenco BLOB presenti ancora il database del contenuto come indicato tramite ExternalBinaryIds insieme il sito. I riferimenti rimanenti nel BLOB elenco si suppone per indicare i file isolati che devono essere eliminati.

Nella figura 6 Misidentification di un BLOB valido come isolati a causa di una condizione di durata

Tuttavia, il provider EBS necessario, naturalmente, prima terminare la scrittura di dati BLOB prima che venga restituito un ID di BLOB in SharePoint. Seconda larghezza di banda della rete e altre condizioni, le prestazioni di I/O possono variare. Pertanto, è possibile che il provider di EBS Impossibile creare un nuovo BLOB, che quindi viene visualizzato nell'elenco BLOB, ma viene completata la scrittura dei dati BLOB dopo aver determinato il ExternalBinaryIds in modo che l'ID del BLOB non sia ancora presente nell'insieme. Di conseguenza, il riferimento al nuovo BLOB rimane nell'elenco BLOB isolato e se si elimina BLOB isolati a questo punto, è accidentalmente eliminare un elemento di contenuto valido e si verifichi una perdita di dati! Per evitare questo problema, l'esempio Garbage Collector controlla l'ora di creazione file e consente di aggiungere solo gli elementi all'elenco BLOB che sono più di un'ora precedente.

Conclusione

Grazie all'integrazione una soluzione di archiviazione esterne con SharePoint, si può migliorare l'efficienza di archiviazione, le prestazioni del sistema e scalabilità di una farm SharePoint. Un altro vantaggio è che questo forza attraversano SharePoint per accedere a contenuto non strutturato. Estrarre dati i database del contenuto tramite connessioni dirette di SQL Server restituisce solo gli identificatori BLOB binari anziché i file effettivi. Tuttavia, provider EBS disporre inoltre svantaggi a causa della complessità della gestione integrità tra metadati nel database del contenuto della farm di SharePoint e l'archivio BLOB esterno.

Per integrare SharePoint con una soluzione di archiviazione esterna, è necessario generare un provider EBS, che è un server COM che implementa l'interfaccia ISPExternalBinaryProvider con i relativi metodi StoreBinary e RetrieveBinary. È possibile creare non gestito e gestito EBS provider, ma tenere presente dei problemi di prestazioni e compatibilità se si decide di utilizzare codice gestito. Tenere inoltre presente che l'interfaccia ISPExternalBinaryProvider non include un metodo DeleteBinary. È necessario in modo esplicito rimuovere BLOB orfani mediante lenta garbage collection e prestare attenzione a evitare condizioni di intervallo che possono comportare l'eliminazione accidentale di elementi BLOB validi.

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.