Comportamento e interazione SMP

Metodi intrinseci e API dell'infrastruttura di gestione

Gli sviluppatori SMP (Storage Management Provider) lavorano con:

• Metodi intrinseci generati da Convert-MofToProvider.exe.
• API dell'infrastruttura di gestione (MI) dal file mi.h per fornire l'implementazione del proprio SMP.

I punti elenco seguenti annotare alcuni metodi intrinseci chiave e MI.

• EnumerateInstances e GetInstance

  EnumerateInstances viene chiamato quando è presente una query per le istanze di una determinata classe. Ad esempio: il cmdlet Get-Object<> di PowerShell esegue il mapping al metodo EnumerateInstances dell'oggetto WMI corrispondente. Questo metodo deve restituire tutte le istanze della classe tramite <il metodo Object>_Post. Poiché WMI chiama frequentemente EnumerateInstances, l'esecuzione dovrebbe essere rapida. A tale scopo, usare una buona gestione della cache.

  GetInstance viene chiamato quando è necessaria un'istanza specifica di una classe, ad esempio (ma non limitata a):

  • Quando l'infrastruttura WMI richiama qualsiasi metodo di questa classe
  • Quando un'applicazione basata su WMI chiama direttamente questo metodo
  • Quando viene richiesta un'istanza della classe tramite le classi Association

  Il metodo GetInstance deve restituire solo l'oggetto specificato tramite <il metodo Object>_Post. Identificatore dell'istanza su cui viene eseguita la query, ovvero la "Chiave" definita in MOF, che in genere è ObjectId, viene recuperata tramite il parametro InstanceName. Questo metodo viene chiamato frequentemente da WMI e deve essere completato rapidamente.

  EnumerateInstances e GetInstance sono obbligatori per classi regolari, ad esempio StorageProvider, StorageSubsystem, PhysicalDisk e così via.

  Per le classi Association, EnumerateInstances, AssociatorInstances e ReferenceInstances sono obbligatorie, mentre GetInstance non è.

• <Oggetto>_Post e MI_PostResult

  Per comprendere la differenza tra il metodo <API MI Object>_Post e MI_PostResult:

  • Si consideri <Object>_Post come restituire un puntatore a un parametro di output.
  • Si consideri MI_PostResult come valore restituito dalla funzione che indica lo stato di esecuzione della funzione.

  È necessario chiamare MI_PostResult una sola volta per ogni metodo WMI "context", disponibile nei parametri di input di ogni metodo WMI. "Context" è un puntatore ai callback WMI. La chiamata di MI_PostResult distruggerà questo puntatore. Pertanto, un metodo WMI non deve mai essere chiamato nel corpo di un altro metodo WMI.

  <L'oggetto>_Post, d'altra parte, può essere chiamato più volte per ogni contesto del metodo WMI. Questo metodo viene in genere usato in EnumerateInstances per restituire più oggetti.

• Imposta<proprietà> e ModifyInstance

  Il metodo intrinseco ModifyInstance non è supportato tramite l'API Di gestione archiviazione di Windows. Per modificare le proprietà di un oggetto, viene utilizzato il metodo estrinsico Set<Property> .

Per altre informazioni sui metodi intrinseci e sulle API MI, vedere gli esempi di API MI di Windows SDK.

Identificazione dell'oggetto

Le interfacce SMP usano i due gruppi di proprietà seguenti per l'identificazione degli oggetti:

• Per la creazione di script e la programmazione: ObjectId e UniqueId

  ObjectId è un identificatore opaco creato e gestito per l'uso dei provider di servizi di gestione e dei relativi client per tenere traccia dell'istanza degli oggetti. Si tratta di una proprietà obbligatoria necessaria per essere univoca a livello globale. Ovvero, due oggetti non devono mai avere lo stesso ObjectId, anche se sono gestiti da SMP separati o si trovano in sottosistemi di archiviazione diversi.

  Se un oggetto è visibile tramite due percorsi diversi, ad esempio due SMP separati che puntano allo stesso sottosistema di archiviazione, lo stesso oggetto può essere visualizzato con due ObjectId diversi. Per determinare se due istanze dell'oggetto sono lo stesso oggetto, utilizzare la proprietà UniqueId.

  UniqueId è una proprietà obbligatoria usata per identificare in modo univoco un'istanza di una classe all'interno di un ambito globale. Questo valore deve essere lo stesso tra due istanze di SSP in esecuzione in server di gestione diversi. A differenza di ObjectId, UniqueId deve essere un valore che il sottosistema di archiviazione persiste anziché il processo del provider di gestione dell'archiviazione.

  UniqueId può essere qualsiasi valore opaco tranne dove diversamente indicato (ad esempio: MSFT_VirtualDisk).

• Per visualizzare: FriendlyName e Name

  Gli utenti finali usano queste due proprietà per identificare un oggetto. FriendlyName è una stringa descrittiva che può essere impostata dagli utenti finali, se SMP supporta tale operazione. FriendlyName non deve essere univoco. Due oggetti di un singolo sottosistema di archiviazione possono condividere lo stesso FriendlyName, anche se questa procedura è sconsigliata.

  SMP imposta la proprietà Name e gli utenti finali non possono modificarla. SMP fornisce informazioni aggiuntive in questa proprietà per facilitare l'identificazione di un oggetto da parte degli utenti finali. Tali informazioni potrebbero trattare aspetti tecnici dell'oggetto. Ad esempio, il nome di un sottosistema di archiviazione può essere l'INDIRIZZO IP o WWN del sottosistema. Il nome è in genere univoco in un determinato ambito. Ad esempio, il nome di un pool di archiviazione deve essere univoco nel sottosistema di archiviazione proprietario.

Gestione errori

Esistono tre tipi di errori nelle interfacce SMP: codici restituiti dell'API sm (Windows Storage Management API ), "Soft errors" e "Hard errors".

I codici restituiti dell'API SM fanno riferimento ai codici di errore elencati come valori restituiti per ognuno dei metodi estristrici SMP. Ad esempio, "5" rappresenta "Parametro non valido". Questi codici di errore vengono restituiti tramite il parametro di output MIReturn definito nella struttura del metodo generata da Convert-MofToProvider.exe. Il valore di MIReturn può essere impostato tramite <Object> _<Method>_Set_MIReturn definito nel file di intestazione dell'oggetto corrispondente.

I metodi estristrici devono sempre usare i codici di errore dell'API SM quando possibile. Quando sono necessarie informazioni aggiuntive, gli SSP possono usare MSFT_ExtendedStatus classe per fornire informazioni aggiuntive sullo stato sulla chiamata di un metodo estrinsico. Questo approccio è preferibile all'uso di errori soft per metodi estristrici.

Gli errori soft fanno riferimento ai messaggi di errore restituiti tramite la classe MSFT_SoftError. Questi errori sono progettati per metodi intrinseci (EnumerateInstances, GetInstance e così via) in cui non è possibile restituire i codici di errore dell'API SM. Per restituire errori soft, le istanze delle classi di errore soft derivate da MSFT_SoftError devono essere costruite e restituite tramite il parametro "MI_Instance error" nel metodo MI_WriteCimError definito in mi.h. Ad esempio, per indicare che "le credenziali corrette sono necessarie" durante l'accesso all'array di archiviazione, è possibile restituire un'istanza di "MSFT_SoftError_NotAuthenticated" durante le chiamate EnumerateInstances sugli oggetti StorageSubsystem. Per gli errori soft, è comunque necessario registrare un risultato di MI_RESULT_OK tramite MI_PostResult.

Gli errori rigidi fanno riferimento agli errori definiti nella struttura MI_Result dal file mi.h . Le API MI restituiscono questi errori. SMP deve evitare di visualizzare direttamente questi errori nelle applicazioni di gestione dell'archiviazione, a meno che non sia assolutamente necessario. Ad esempio, per i "parametri non validi", gli SSP devono usare MIReturn per visualizzare il codice di errore dell'API SM "5" - "Parametro non valido" invece di basarsi sull'applicazione di gestione archiviazione per utilizzare MI_RESULT_INVALID_PARAMETER.

Piscina primordiale

Un pool primordiale, noto anche come pool di archiviazione disponibile, è dove la capacità di archiviazione viene disegnata e restituita nella creazione e eliminazione di pool di archiviazione concreti. I pool primordiali non possono essere creati, eliminati o modificati.

Gli SMP devono fornire almeno un pool primordiale. Quando un disco fisico viene aggiunto a un pool di archiviazione concreto, il disco fisico deve comunque essere considerato come parte del pool primordiale.

Creazione di report sulle dimensioni

Esistono due casi speciali da discutere per vari campi di dimensioni degli oggetti pool di archiviazione: capacità da unità di riserva ad accesso frequente e capacità da unità non integre.

Una volta che un'unità viene nominata come unità di riserva a caldo, la sua capacità deve essere inclusa nell'AllocateSize del pool primordiale corrispondente. Tuttavia, la capacità dell'unità non deve essere inclusa nelle dimensioni di un pool di cemento, anche se l'array di archiviazione supporta la devozione di un'unità di riserva a caldo a un pool di cemento specifico. Dopo che un'unità di riserva a caldo è dedicata a un particolare pool di cemento, la capacità dell'unità non deve essere inclusa nell'oggetto AllocateSize del pool di cemento fino a quando non sostituisce effettivamente un'unità utilizzata. Quando viene aggiunto a un pool di cemento, CanPooled deve essere FALSE per l'oggetto Disco fisico di questa unità di riserva a caldo. È necessario creare un'associazione tra questo oggetto Disco fisico e l'oggetto Pool di archiviazione del pool di cemento.

La capacità delle unità con HealthStatus di "Non integro" non deve essere inclusa in alcun campo di dimensioni da pool primordiale o pool di cemento.

Associazioni

L'API SM include classi di associazione che definiscono le relazioni tra gli oggetti di archiviazione. Con queste classi di associazione, è facile attraversare la gerarchia degli oggetti di archiviazione per ottenere oggetti correlati per un determinato oggetto. Per il modulo PowerShell di archiviazione, il piping dei cmdlet viene ottenuto tramite le classi di associazione. Ad esempio, dato un oggetto Disco virtuale, gli utenti possono ottenere il pool di archiviazione proprietario dell'oggetto Disco virtuale tramite il cmdlet seguente:

    PS> Get-VirtualDisk –FriendlyName MyVirtualDisk | Get-StoragePool

Nella parte restante di questa sezione viene illustrata l'implementazione delle classi di associazione. I metodi nelle note vengono generati da Convert-MofToProvider.exe per ogni classe di associazione. Le note usano XToY come classe di associazione di esempio; il codice pseudo usa StoragePoolToVirtualDisk come esempio.

• EnumerateInstances e GetInstance

      - XToY\_EnumerateInstances returns association objects (XToY objects) for ALL X objects
    
    <!-- end list -->
    
        void MI_CALL SAMPLE_StoragePoolToVirtualDisk_EnumerateInstances( ... )
        {
            ...
        
        /** This method should return association objects for ALL Storage Pools. **/
        
            // for each storage pool
        
                // for each virtual disk that's associated with this storage pool
        
                    // create the StoragePoolToVirtualDisk association object
                    // set the storage pool object and virtual disk object to this association object
                    // post the association object
                
                // end for
        
            // end for
        
            ...
        }

• AssociatorInstances

      - AssociatorInstances method returns regular objects instead of association objects
      - XToY\_AssociatorInstancesX should return all associated Y object(s) for the X specified
      - XToY\_AssociatorInstancesY should return all associated X object(s) for the Y specified
    
    <!-- end list -->
    
        void MI_CALL SAMPLE_StoragePoolToVirtualDisk_AssociatorInstancesStoragePool(...)
        {
            ...
        
        /** This method should return VIRTUAL DISK object(s) for the 
        STORAGE POOL specified. **/
        
            // for each virtual disk that's associated with this storage pool
        
                // create the virtual disk object
                // post the virtual disk object
                
            // end for
        
            ...
        }
        
        void MI_CALL SAMPLE_StoragePoolToVirtualDisk_AssociatorInstancesVirtualDisk(...)
        {
            ...
        
        /** This method should return STORAGE POOL object(s) for the 
        VIRTUAL DISK specified. **/
        
            // for each storage pool that's associated with this virtual disk
        
                // create the storage pool object
                // post the storage pool object
                
            // end for
        
            ...
        }

• ReferenceInstances

      - ReferenceInstances is similar to AssociatorInstances except that these methods return association (XToY) objects instead of regular objects
      - XToY\_ReferenceInstancesX should return XToY object(s) for X specified
      - XToY\_ReferenceInstancesY should return YToX object(s) for Y specified
    
    <!-- end list -->
    
        void MI_CALL SAMPLE_StoragePoolToVirtualDisk_ReferenceInstancesStoragePool(...)
        {
            ...
        
        /** This method should return StoragePoolToVirtualDisk 
        ASSOCIATION object(s) for the STORAGE POOL specified. **/
        
            // for each virtual disk that's associated with this storage pool
        
                // create the StoragePoolToVirtualDisk association object
                // set the storage pool and virtual disk to this association object
                // post the association object
                
            // end for
        
        
            ...
        }
        
        void MI_CALL SAMPLE_StoragePoolToVirtualDisk_ReferenceInstancesVirtualDisk(...)
        {
            ...
        
        /** This method should return StoragePoolToVirtualDisk 
        ASSOCIATION object(s) for the VIRTUAL DISK specified. **/
        
            // for each storage pool that's associated with this virtual disk
        
                // create the StoragePoolToVirtualDisk association object
                // set the storage pool and virtual disk to this association object
                // post the association object
                
            // end for
        
            ...
        }

Gestione della cache

Quando il modello SMP viene caricato, deve inizializzare una cache di oggetti di archiviazione. Questa inizializzazione garantisce un tempo di risposta rapido quando la manutenzione delle chiamate API come oggetti può essere recuperata direttamente dalla cache SMP. Questa cache deve essere mantenuta sincronizzata con le modifiche apportate all'oggetto in banda e le modifiche apportate all'oggetto fuori banda.

Le modifiche apportate all'oggetto in banda includono le modifiche apportate tramite l'istanza SMP corrente. Ad esempio, se un disco virtuale viene creato tramite l'istanza SMP corrente:

• Alla cache deve essere aggiunto un nuovo oggetto Disco virtuale.
• Gli oggetti associati, ad esempio il pool di archiviazione proprietario e gli oggetti porta di destinazione associati, devono essere aggiornati anche.

Le modifiche fuori banda includono le modifiche apportate tramite strumenti proprietari del fornitore e SSP che ospitano in altri computer. Ad esempio, se un disco virtuale viene creato tramite strumenti proprietari del fornitore, è necessario inviare un evento dal sottosistema di archiviazione ai SMP per attivare un aggiornamento della cache.

SMP deve anche aggiornare la cache quando viene chiamato il metodo Discover dalla classe del provider di archiviazione. L'applicazione di gestione archiviazione chiama questo metodo per reimpostare e ricompilare la cache in caso di evento come il riavvio del servizio o il riavvio del sistema.

Se non è possibile inizializzare l'intera cache all'avvio (a causa di troppi oggetti o perché non è possibile eseguire rapidamente), è necessario caricare nella cache solo gli oggetti del provider di archiviazione e del sottosistema di archiviazione. Le applicazioni esamineranno la proprietà CurrentCacheLevel nell'oggetto Sottosistema di archiviazione per sapere in che modo è stata riempita la cache. L'utente finale o l'applicazione caricano in modo esplicito il resto della cache tramite il metodo Discover.

Operazioni asincrone

Qualsiasi operazione che richiede più di 30 secondi per il completamento deve restituire un oggetto Processo di archiviazione. È probabile che i metodi che contengono un parametro di output CreatedStorageJob siano di questo tipo di operazione. Gli SSP devono implementare tutti questi metodi come operazioni asincrone e restituire gli oggetti Processo di archiviazione per tali metodi. Un oggetto Processo di archiviazione deve essere restituito al chiamante entro 30 secondi; in caso contrario, il chiamante può verificarsi un timeout se attende troppo tempo e non ha ancora ricevuto l'oggetto Processo di archiviazione.

Le applicazioni (o "client WMI") hanno la possibilità di specificare se un metodo deve essere "RunAsJob" o meno. L'API SM usata dalle applicazioni contiene questo parametro Boolean RunAsJob aggiuntivo e il parametro di output CreatedStorageJob. Nel frattempo, i metodi corrispondenti nelle interfacce SMP hanno solo il parametro CreatedStorageJob. Tuttavia, indipendentemente dal valore di "RunAsJob", gli SSP devono restituire sempre oggetti Processo di archiviazione per questi metodi.

Gli scenari seguenti illustrano la sequenza di chiamate di operazioni asincrone. CreateVirtualDisk viene usato come esempio:

• Se "RunAsJob" è impostato su TRUE

  Quando viene richiamato CreateVirtualDisk, gli SSP devono eseguire l'inizializzazione per il metodo, avviare un processo nel sottosistema di archiviazione e restituire un oggetto Processo di archiviazione al chiamante entro 30 secondi. Tuttavia, il sottosistema di archiviazione può richiedere qualsiasi quantità di tempo per completare l'operazione. Il chiamante eseguirà il polling dello stato del processo durante questo periodo.

  I thread di lavoro devono essere usati per eseguire i processi. Ai fini dell'efficienza, gli SSP possono aggiornare gli attributi correlati allo stato del processo (ad esempio, PercentComplete) solo quando il chiamante esegue il polling dello stato del processo.

• Se "RunAsJob" è impostato su FALSE

  Il chiamante verrà bloccato nel metodo CreateVirtualDisk fino a quando il metodo non viene restituito. L'API SM esegue automaticamente il blocco e il polling stesso. Questo tipo di chiamante è in genere un client non interattivo dall'utente (ad esempio, uno strumento di scripting) che preferisce il meccanismo di blocco.

  Poiché l'unico modo per ottenere informazioni su un oggetto appena creato consiste nell'associazione tra questo oggetto e l'oggetto Processo di archiviazione corrispondente, i provider di servizi di archiviazione devono mantenere un oggetto Processo di archiviazione per almeno 24 ore prima di rimuoverlo dalla cache. Per altre operazioni che non restituiscono un oggetto appena creato (ad esempio, un'operazione DeleteObject), non è necessaria un'associazione e l'oggetto Processo di archiviazione deve rimanere attivo solo per 15 minuti.

Per i riavvii imprevisti del sistema nelle console di gestione, gli SSP devono mantenere una cache di oggetti StorageJob in una posizione fisica, ad esempio nell'array di archiviazione e ricaricare la cache al riavvio del sistema.

Controllo del tempo di vita del provider

Un SMP può essere implementato come provider accoppiato o disaccoppiato. Per la differenza tra questi due tipi di provider, vedere la documentazione MSDN di WMI.

Un provider disaccoppiato viene caricato e ospitato in un processo specifico del fornitore. Questo processo è in genere un servizio sempre in esecuzione.

L'avvio di un provider può richiedere molto tempo perché comporta il ricaricamento della cache. Se l'avvio SMP richiede più di un secondo o così via per il caricamento, è consigliabile implementare un provider disaccoppiato per gestire gli oggetti di archiviazione tramite una cache persistente. Questo approccio consente di aumentare le prestazioni complessive e la velocità di risposta delle applicazioni che usano l'API windows SM per gestire il modello SMP.

L'esempio DecoupledHost di Windows SDK fornisce altri dettagli sui provider disaccoppiati.

Indicazioni

Gli sviluppatori di applicazioni spesso vogliono sapere quando lo stato di un oggetto cambia man mano che cambia. È possibile farlo sottoscrivendo le indicazioni WMI. Le indicazioni sono un tipo diverso di classe; vengono esposti in modo asincrono, a volte fuori banda da qualsiasi operazione di gestione e non vengono mantenuti. Invece di implementare i metodi intrinseci familiari(ovvero EnumerateInstances/GetInstance), sono disponibili nuovi metodi che devono essere supportati.

Esistono quattro tipi di indicazioni:

• Arrivo: questa indicazione viene usata quando un dispositivo o un'istanza dell'oggetto viene aggiunta al sottosistema. Ad esempio: aggiunta di un nuovo disco fisico al sottosistema o creazione di un disco virtuale.
• Partenza: questa indicazione viene usata quando un dispositivo o un'istanza dell'oggetto viene rimossa dal sottosistema. Ad esempio: rimozione di un disco fisico dal sottosistema o eliminazione di un pool di archiviazione.
• Modify: questa indicazione viene usata quando una proprietà importante cambia in un oggetto esistente. Le modifiche di HealthStatus e OperationalStatus devono attivare almeno un'indicazione Modify. È consigliabile indicare una modifica in qualsiasi altra proprietà correlata allo stato operativo di un oggetto .
• Avviso: questa indicazione viene usata per avvisare l'applicazione di un potenziale problema. Attualmente, l'unico avviso definito è per notificare quando viene raggiunta una soglia di thin provisioning.

Per implementare le indicazioni, esistono due nuovi metodi intrinseci che devono essere implementati per ogni classe di indicazione:

• EnableIndication: è stata effettuata una richiesta di sottoscrizione alla classe di indicazione. L'elemento indicationContext deve essere salvato in modo che sia disponibile per pubblicare un'indicazione in un secondo momento.
• DisableIndication: non sono presenti altri sottoscrittori per la classe di indicazione. La pulizia deve essere eseguita e non devono essere pubblicate altre indicazioni per questa classe. indicationContext viene distrutto in questo momento.

Distribuzione

Gli SMP vengono installati nei "server di gestione" selezionati. Questi server possono essere raggruppati per garantire la ridondanza. Altri server accedono alle risorse di archiviazione allocate tramite iSCSI o Fiber Channel. Tutti questi computer possono essere gestiti dai server che eseguono l'interfaccia utente file server da Server Manager.

I fornitori di archiviazione, tuttavia, sono invitati a scegliere il modello di distribuzione più adatto alle proprie esigenze.

Modello di sicurezza

L'interfaccia SMP supporta il modello Single Sign-On (SSO) usando le credenziali di sicurezza di Windows.

Nel modello SSO, un utente accede a un "computer di gestione" con le credenziali di Windows una sola volta e ottiene automaticamente l'accesso a tutti gli asset di archiviazione a cui dispone dell'autorizzazione di accesso. Non è necessario avere più credenziali per l'accesso al sottosistema di archiviazione.

L'interfaccia consente anche agli amministratori di archiviazione di gestire il controllo di accesso sui singoli asset di archiviazione. Per ogni asset di archiviazione, gli amministratori di archiviazione possono concedere diritti di accesso diversi a qualsiasi utente di Windows tramite i metodi GetSecurityDescriptor e SetSecurityDescriptor. Di conseguenza, le pmi, a differenza del modello VDS, possono ora ricevere richieste da qualsiasi tipo di account utente.

Per implementare il modello SSO, un SMP deve autenticare i client Windows nel sottosistema di archiviazione. Il sottosistema di archiviazione deve rendere persistenti le informazioni del descrittore di sicurezza per ogni asset di archiviazione. Per implementare l'autenticazione, i fornitori di archiviazione hanno due opzioni:

• Eseguire l'autenticazione nel sottosistema (scelta consigliata)
• Eseguire l'autenticazione in ogni istanza SMP.

Entrambe le opzioni richiedono che venga stabilita una relazione di trust tra SMP e il sottosistema di archiviazione in modo che il descrittore di sicurezza e le informazioni sull'identità utente possano essere passate in modo sicuro.

Per implementare l'autenticazione e l'autorizzazione senza problemi nel sottosistema di archiviazione, è consigliabile usare il collegamento tra SMP e il sottosistema di archiviazione per implementare Kerberos, NTLM o SPNego. Se il sottosistema di archiviazione dispone di un server Web, il protocollo "NTLM su HTTP" [MS-NLMP] potrebbe essere più utile. I fornitori di archiviazione possono scegliere di mantenere i protocolli proprietari per implementare il modello SSO. Tuttavia, questo approccio non è consigliato perché può comportare più lavoro o configurazione rispetto all'implementazione di uno dei protocolli di autenticazione supportati da Windows.

Per supportare i criteri di sicurezza di Windows, il sottosistema di archiviazione deve ottenere le "informazioni sul token dell'utente", che include il SID (Security Identifier) dell'utente e i SID di qualsiasi gruppo di cui l'utente è membro. Se viene implementato il protocollo Kerberos, NTLM o SPNego, il sottosistema di archiviazione otterrà le informazioni sul token dell'utente come parte del protocollo. Se il protocollo proprietario di un fornitore viene usato tra SMP e il sottosistema di archiviazione, il sottosistema di archiviazione può eseguire query sulle informazioni sul token dell'utente da Active Directory tramite LDAP (Lightweight Directory Access Protocol) e esaminare l'attributo tokenGroupsGlobalAndUniversal o Object-Sid nell'oggetto account dell'utente.

Con le informazioni sul token dell'utente, per applicare i criteri di sicurezza di Windows, il sottosistema di archiviazione deve implementare l'algoritmo di controllo di accesso descritto in [MS-DTYP].

Se un fornitore di archiviazione sceglie di non supportare questo modello SSO, è consigliabile che SMP segua il modello di sicurezza da VDS, consentendo solo le operazioni avviate dagli account amministratore. Questo controllo, tuttavia, deve ora essere eseguito dal SMP stesso.