Tâches de pré-installation
Vous devez effectuer les tâches suivantes avant l’installation et la configuration de Provisioning Services.
Sélectionner et configurer la base de données MS SQL
Une seule base de données est associée à une batterie. Vous pouvez installer le logiciel de base de données Provisioning Services sur :
- Une base de données SQL existante, si cette machine peut communiquer avec tous les serveurs Provisioning Server de la batterie.
- Une nouvelle machine de base de données SQL Express, créée à l’aide de SQL Express, un logiciel gratuit de Microsoft.
Dans un environnement de production, il est recommandé d’installer la base de données et le logiciel Provisioning Server sur des serveurs distincts, afin d’éviter une répartition déséquilibrée durant l’équilibrage de charge.
Il se peut que l’administrateur de base de données préfère créer la base de données Provisioning Services. Dans ce cas, fournissez à l’administrateur de base de données MS SQL le fichier créé à l’aide de l’outil DbScript.exe. Cet outil est installé avec le logiciel Provisioning Services.
Dimensionnement de la base de données
Pour plus d’informations sur le dimensionnement de la base de données, consultez Estimer la taille d’une base de données.
Lorsque la base de données est créée, sa taille initiale est de 20 Mo avec une taille de croissance de 10 Mo. La taille initiale du journal de base de données est de 10 Mo avec une taille de croissance de 10 %.
La quantité d’espace minimum requis est de 112 Ko, ce qui ne change pas. Cela comprend ce qui suit :
- L’enregistrement Database Version requiert approximativement 32 Ko.
- L’enregistrement Farm requiert approximativement 8 Ko.
- L’enregistrement Disk Create requiert approximativement 16 Ko.
- Les notifications requièrent approximativement 40 Ko.
- L’enregistrement Server Mapped requiert approximativement 16 Ko.
La quantité d’espace variable requis, basée sur des objets, est la suivante :
- Accès et regroupements (chaque)
- Un groupe d’utilisateur qui a accès au système requiert approximativement 50 Ko.
- Un enregistrement Site requiert approximativement 4 Ko.
- Une collection requiert approximativement 10 Ko.
- Farm View (chaque objet)
- Farm View requiert approximativement 4 Ko.
- Une relation FarmView/Device requiert approximativement 5 Ko.
- Site View (chaque objet)
- Site View requiert approximativement 4 Ko.
- Une relation SiteView/Device requiert approximativement 5 Ko.
- Machine cible (chaque)
- Une machine cible requiert approximativement 2 Ko
- Device Bootstrap requiert approximativement 10 Ko.
- La relation Device/Disk requiert approximativement 35 Ko.
- La relation Device/Printer requiert approximativement 1 Ko.
- Device Personality requiert approximativement 1 Ko.
- Device Status requiert approximativement 1 KB lorsqu’une machine est démarrée.
- DeviceCustomProperty requiert approximativement 2 Ko.
- Disque (chaque)
- Un disque unique requiert approximativement 1 Ko.
- DiskVersion requiert approximativement 3 Ko.
- Disk Locator requiert approximativement 10 Ko.
- DiskLocatorCustomProperty requiert approximativement 2 Ko.
- Provisioning Server (chaque)
- Un serveur requiert approximativement 5 Ko.
- ServerIP requiert approximativement 2 Ko.
- Server Status lorsqu’un serveur est démarré requiert approximativement 1 KB.
- ServerCustomProperty requiert approximativement 2 Ko.
- Magasin (chaque)
- Store requiert approximativement 8 Ko.
- La relation Store/Server requiert approximativement 4 Ko.
- Mise à jour du disque (chaque)
- VirtualHostingPool requiert approximativement 4 Ko.
- UpdateTask requiert approximativement 10 Ko.
- DiskUpdateDevice requiert approximativement 2 Ko.
- Chaque relation DiskUpdateDevice/Disk requiert approximativement 35 Ko.
- la relation Disk/UpdateTask requiert approximativement 1 Ko.
Les modifications suivantes entrainent l’augmentation des conditions requises en matière de taille :
- Chaque tâche traitée (par exemple : fusionnement des versions de vDisk) requiert approximativement 2 Ko.
- Si la fonction d’audit est activée, chaque modification effectuée par l’administrateur dans la console, MCLI ou l’interface PowerShell requiert approximativement 1 Ko.
Mise en miroir de la base de données
Pour que Provisioning Services prenne en charge la mise en miroir de base de données MS SQL, la base de données doit être configurée avec High-safety mode with a witness (synchronous).
Si vous avez l’intention d’utiliser la fonctionnalité de mise en miroir de bases de données, le client natif SQL est requis sur le serveur. Si ce dernier n’existe pas, l’option permettant d’installer le client natif SQL x64 ou x86 s’affiche lorsque SQL est installé.
Pour plus d’informations sur la manière de configurer et d’utiliser la mise en miroir de base de données, consultez la section Mise en miroir de la base de données.
Mise en cluster de base de données
Pour implémenter la mise en cluster de base de données, suivez les instructions de Microsoft, puis réexécutez l’assistant de configuration de Provisioning Services. Aucune étape supplémentaire n’est requise car l’assistant considère le cluster comme un SQL Server unique.
Configuration de l’authentification
Provisioning Services utilise l’authentification Windows pour accéder à la base de données. L’authentification Microsoft SQL Server n’est prise en charge exceptée par l’assistant de configuration.
-
Autorisations d’accès des utilisateurs à l’assistant de configuration
Les autorisations MS SQL suivantes sont nécessaires pour l’utilisateur qui exécute l’assistant de configuration :
- dbcreator pour la création de la base de données
- security admin pour la création des connexions SQL pour les services de streaming et SOAP
Si vous utilisez MS SQL Express dans un environnement de test, vous pouvez choisir de donner les privilèges sysadmin à l’utilisateur qui exécute l’assistant de configuration (le plus haut niveau de privilège au niveau de la base de données).
Autrement, si l’administrateur de la base de données a fourni une base de données vide, l’utilisateur qui exécute l’assistant de configuration doit être le propriétaire de la base de données et disposer du droit View any definition (défini par l’administrateur de la base de données lorsque la base de données vide est créée).
Autorisations d’accès au compte de service
Le contexte utilisateur pour les services de streaming et SOAP nécessite les autorisations d’accès à la base de données suivantes :
- db_datareader
- db_datawriter
- Autorisations d’exécution sur les procédures stockées
les rôles de base de données Datareader et Datawriter sont automatiquement configurés pour compte d’utilisateur des services de streaming et SOAP à l’aide de l’assistant de configuration. L’assistant de configuration attribue ces autorisations si l’utilisateur dispose des autorisations security admin. De plus, l’utilisateur du service doit disposer des privilèges système suivants :
- Exécuter en tant que service
- Accès en lecture au registre
- Accès à Program Files\Citrix\Provisioning Services
- Accès en lecture et écriture à n’importe quel emplacement de vDisk
Déterminez le compte d’utilisateur pris en charge sous lequel seront exécutés les services de streaming et SOAP :
-
compte de service réseau ;
compte local doté des privilèges minimaux qui authentifie sur le réseau en tant que compte de la machine de domaine d’ordinateurs ;
-
compte d’utilisateur spécifié (requis lors de l’utilisation d’un partage Windows), qui peut être un compte d’utilisateur de domaine ou de groupe de travail ;
Pour que Provisioning Services prenne en charge les licences KMS, le compte d’utilisateur du serveur SOAP doit être membre du groupe Administrateurs local.
Comme l’authentification n’est pas fréquente dans les environnements de groupe de travail, des comptes d’utilisateurs dotés d’un minimum de privilèges doivent être créés sur chaque serveur et chaque instance doit posséder les mêmes informations d’identification.
Déterminez l’option de sécurité qu’il convient le mieux d’utiliser dans cette batterie (il n’est possible de sélectionner qu’une option par batterie et votre choix affecte les groupes d’utilisateurs et l’administration basée sur les rôles) :
- Use Active Directory groups for security (par défaut) : sélectionnez cette option dans le cas d’un domaine Windows exécutant Active Directory. Cette option vous permet d’utiliser Active Directory pour les rôles d’administration de Provisioning Services. Remarque : les domaines Windows 2000 ne sont pas pris en charge.
- Use Windows groups for security : sélectionnez cette option si vous vous trouvez sur un serveur unique ou dans un groupe de travail. Cette option vous permet d’utiliser des groupes/l’utilisateur local sur ce serveur particulier pour les rôles d’administration de Provisioning Services.
les utilisateurs de la console n’ont pas d’accès direct à la base de données.
Les permissions minimales requises pour une fonctionnalité Provisioning Services supplémentaire comprennent :
- Provisioning Services XenDesktop Setup Wizard, Streamed VM Setup Wizard, et ImageUpdate service
- Permissions minimales vCenter, SCVMM et XenServer
- Permissions pour l’utilisateur actuel sur un contrôleur XenDesktop existant
- Un compte d’utilisateur de la console Provisioning Services configuré en tant qu’administrateur XenDesktop et ajouté à un groupe PVS Site Admin ou supérieur
- Permission Active Directory Create Accounts pour créer des comptes dans la console. Pour utiliser des comptes existants, les comptes Active Directory doivent exister dans une unité d’organisation connue pour sélection.
- Si vous utilisez des Personal vDisks avec XenDesktop, le compte d’utilisateur du serveur SOAP doit posséder les privilèges d’administrateur complet XenDesktop.
- Synchronisation de compte AD : créer, réinitialiser et supprimer des permissions
- vDisk : privilèges requis pour effectuer les tâches de maintenance de volume
Sécurité Kerberos
Par défaut, la console Provisioning Services, Imaging Wizard, le composant logiciel enfichable PowerShell et MCLI utilisent l’authentification Kerberos lors des communications avec le service SOAP de Provisioning Services dans un environnement Active Directory. Une partie de l’architecture Kerberos est pour l’enregistrement d’un service (créer un nom principal de service, SPN) avec le contrôleur de domaine (Kerberos Key Distribution Center). L’enregistrement est essentiel car il permet à Active Directory d’identifier le compte sur lequel le service SOAP de Provisioning Services est exécuté. Si l’enregistrement n’est pas réalisé, l’authentification Kerberos échoue et Provisioning Services retourne à l’utilisation de l’authentification NTLM.
Le service SOAP de Provisioning Services s’enregistre à chaque démarrage du service et annule son enregistrement lors de l’arrêt du service. Toutefois, l’enregistrement échoue si le compte d’utilisateur du service ne dispose pas des autorisations nécessaires. Par défaut, le compte Network Service et les administrateurs de domaine possèdent des permissions que les comptes d’utilisateur de domaine normaux ne possèdent pas.
Pour contourner ce problème d’autorisation, effectuez l’une des opérations suivantes :
- utilisez un compte différent qui possède des permissions pour créer des SPN ;
- attribuez des permissions au compte de service. | | | | —————- | ———————— | | Account Type | Permission | | Computer Account | Write Validated SPN | | User Account | Write Public Information |