Dans le cadre de notre activité, nous souhaitons utiliser WSS pour la mise à
disposition d'espaces collaboratifs dédiés aux projets.
Les utilisateurs seront à la fois internes à la société mais également des
intervenants extérieurs.
Nous allons donc installer WSS sur un serveur initialement dédié
exclusivement à l'hébergement du SQL Serveur 2000 pour le fonctionnement de
nos sites web. La machine est donc situé en DMZ et nous souhaitons réaliser
une installation de WSS en mode serveur autonome. Les espaces collaboratifs
ne pourront donc pas bénéficier de notre annuaire LDAP interne (ni
localement sur le serveur de production en question).
Par ailleurs, nous n'avons à l'heure actuelle aucune idée des membres à
pré-enregistrer, cette gestion se fera donc au quotidien et nous souhaitons
que les administrateurs fonctionnels nommés pour chacun des sites WSS soient
autonomes pour ajouter des participants.
Lors de nos premiers tests, nous nous trouvons confronté à une limite que
nous n'avions pas constaté lors de notre évaluation initiale (via
sharepointsite.net) : la création d'un nouveau compte (fonctionnalité
"Ajouter un utilisateur") dans l'interface d'administration d'un site ne
permet que de "choisir un utilisateur" préalablement créé localement sur le
serveur.
En l'état actuel des choses, cela représente une limite très forte au
produit puisqu'il est alors impossible à des administrateurs fonctionnels de
sites WSS de procéder sans avoir recours systématiquement à notre
administrateur réseau pour qu'il crée le compte système.
J'ai donc deux questions :
- est-il possible de contourner cette limite, notamment en adaptant notre
paramétrage au niveau de l'installation ?
- si non, est-il possible de prévoir un AD dédié à WSS mais qui n'impose
pas au serveur d'être promu en contrôleur de domaine (serveur de production
!) ? Quel en serait l'impact, les risques ou les précautions à prendre ?
Un grand merci d'avance pour les éclairages que vous pourriez nous apporter
à ce sujet.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Renaud Comte
Votre probléme est trés simple
WSS nécessite des comptes NT pour gérér l'identification puis les autorisations
Et donc, vous demande de créez des comptes NT locaux ou sur un AD distant reliés aux serveur.
Je vous conseille de monter un AD en DMZ puis ensuite au choix
-WSS en mode pilotage d'Active Directory : di mode en hebergement - WSS classique : a vous de deleguer un droit de création à vos utilisateurs admin
Voila :)
Renaud COMTE [MVP] --------------------------------- http://blogs.developpeur.org/themit/ http://blog.spsclerics.com/
Bonjour,
Dans le cadre de notre activité, nous souhaitons utiliser WSS pour la mise à disposition d'espaces collaboratifs dédiés aux projets. Les utilisateurs seront à la fois internes à la société mais également des intervenants extérieurs. Nous allons donc installer WSS sur un serveur initialement dédié exclusivement à l'hébergement du SQL Serveur 2000 pour le fonctionnement de nos sites web. La machine est donc situé en DMZ et nous souhaitons réaliser une installation de WSS en mode serveur autonome. Les espaces collaboratifs ne pourront donc pas bénéficier de notre annuaire LDAP interne (ni localement sur le serveur de production en question).
Par ailleurs, nous n'avons à l'heure actuelle aucune idée des membres à pré-enregistrer, cette gestion se fera donc au quotidien et nous souhaitons que les administrateurs fonctionnels nommés pour chacun des sites WSS soient autonomes pour ajouter des participants.
Lors de nos premiers tests, nous nous trouvons confronté à une limite que nous n'avions pas constaté lors de notre évaluation initiale (via sharepointsite.net) : la création d'un nouveau compte (fonctionnalité "Ajouter un utilisateur") dans l'interface d'administration d'un site ne permet que de "choisir un utilisateur" préalablement créé localement sur le serveur. En l'état actuel des choses, cela représente une limite très forte au produit puisqu'il est alors impossible à des administrateurs fonctionnels de sites WSS de procéder sans avoir recours systématiquement à notre administrateur réseau pour qu'il crée le compte système. J'ai donc deux questions : - est-il possible de contourner cette limite, notamment en adaptant notre paramétrage au niveau de l'installation ? - si non, est-il possible de prévoir un AD dédié à WSS mais qui n'impose pas au serveur d'être promu en contrôleur de domaine (serveur de production !) ? Quel en serait l'impact, les risques ou les précautions à prendre ?
Un grand merci d'avance pour les éclairages que vous pourriez nous apporter à ce sujet.
Cordialement,
Pascal.
Votre probléme est trés simple
WSS nécessite des comptes NT pour gérér l'identification puis les autorisations
Et donc, vous demande de créez des comptes NT locaux ou sur un AD distant
reliés aux serveur.
Je vous conseille de monter un AD en DMZ puis ensuite au choix
-WSS en mode pilotage d'Active Directory : di mode en hebergement
- WSS classique : a vous de deleguer un droit de création à vos utilisateurs
admin
Voila :)
Renaud COMTE [MVP]
---------------------------------
http://blogs.developpeur.org/themit/
http://blog.spsclerics.com/
Bonjour,
Dans le cadre de notre activité, nous souhaitons utiliser WSS pour la
mise à
disposition d'espaces collaboratifs dédiés aux projets.
Les utilisateurs seront à la fois internes à la société mais également
des
intervenants extérieurs.
Nous allons donc installer WSS sur un serveur initialement dédié
exclusivement à l'hébergement du SQL Serveur 2000 pour le
fonctionnement de nos sites web. La machine est donc situé en DMZ et
nous souhaitons réaliser une installation de WSS en mode serveur
autonome. Les espaces collaboratifs ne pourront donc pas bénéficier de
notre annuaire LDAP interne (ni localement sur le serveur de
production en question).
Par ailleurs, nous n'avons à l'heure actuelle aucune idée des membres
à pré-enregistrer, cette gestion se fera donc au quotidien et nous
souhaitons que les administrateurs fonctionnels nommés pour chacun des
sites WSS soient autonomes pour ajouter des participants.
Lors de nos premiers tests, nous nous trouvons confronté à une limite
que
nous n'avions pas constaté lors de notre évaluation initiale (via
sharepointsite.net) : la création d'un nouveau compte (fonctionnalité
"Ajouter un utilisateur") dans l'interface d'administration d'un site
ne
permet que de "choisir un utilisateur" préalablement créé localement
sur le
serveur.
En l'état actuel des choses, cela représente une limite très forte au
produit puisqu'il est alors impossible à des administrateurs
fonctionnels de
sites WSS de procéder sans avoir recours systématiquement à notre
administrateur réseau pour qu'il crée le compte système.
J'ai donc deux questions :
- est-il possible de contourner cette limite, notamment en adaptant
notre
paramétrage au niveau de l'installation ?
- si non, est-il possible de prévoir un AD dédié à WSS mais qui
n'impose
pas au serveur d'être promu en contrôleur de domaine (serveur de
production
!) ? Quel en serait l'impact, les risques ou les précautions à prendre
?
Un grand merci d'avance pour les éclairages que vous pourriez nous
apporter à ce sujet.
WSS nécessite des comptes NT pour gérér l'identification puis les autorisations
Et donc, vous demande de créez des comptes NT locaux ou sur un AD distant reliés aux serveur.
Je vous conseille de monter un AD en DMZ puis ensuite au choix
-WSS en mode pilotage d'Active Directory : di mode en hebergement - WSS classique : a vous de deleguer un droit de création à vos utilisateurs admin
Voila :)
Renaud COMTE [MVP] --------------------------------- http://blogs.developpeur.org/themit/ http://blog.spsclerics.com/
Bonjour,
Dans le cadre de notre activité, nous souhaitons utiliser WSS pour la mise à disposition d'espaces collaboratifs dédiés aux projets. Les utilisateurs seront à la fois internes à la société mais également des intervenants extérieurs. Nous allons donc installer WSS sur un serveur initialement dédié exclusivement à l'hébergement du SQL Serveur 2000 pour le fonctionnement de nos sites web. La machine est donc situé en DMZ et nous souhaitons réaliser une installation de WSS en mode serveur autonome. Les espaces collaboratifs ne pourront donc pas bénéficier de notre annuaire LDAP interne (ni localement sur le serveur de production en question).
Par ailleurs, nous n'avons à l'heure actuelle aucune idée des membres à pré-enregistrer, cette gestion se fera donc au quotidien et nous souhaitons que les administrateurs fonctionnels nommés pour chacun des sites WSS soient autonomes pour ajouter des participants.
Lors de nos premiers tests, nous nous trouvons confronté à une limite que nous n'avions pas constaté lors de notre évaluation initiale (via sharepointsite.net) : la création d'un nouveau compte (fonctionnalité "Ajouter un utilisateur") dans l'interface d'administration d'un site ne permet que de "choisir un utilisateur" préalablement créé localement sur le serveur. En l'état actuel des choses, cela représente une limite très forte au produit puisqu'il est alors impossible à des administrateurs fonctionnels de sites WSS de procéder sans avoir recours systématiquement à notre administrateur réseau pour qu'il crée le compte système. J'ai donc deux questions : - est-il possible de contourner cette limite, notamment en adaptant notre paramétrage au niveau de l'installation ? - si non, est-il possible de prévoir un AD dédié à WSS mais qui n'impose pas au serveur d'être promu en contrôleur de domaine (serveur de production !) ? Quel en serait l'impact, les risques ou les précautions à prendre ?
Un grand merci d'avance pour les éclairages que vous pourriez nous apporter à ce sujet.
