Bonjour,
J'ai un problème avec le script suivant
$ldapQuery = "(&(objectclass=user))"
$de = [ADSI]"LDAP://*.*.*.*/ou=*,OU=*,dc=*,dc=*"
$ads = new-object system.directoryservices.directorysearcher -argumentlist $de,$ldapQuery
$complist = $ads.findall()
foreach ($i in $complist) {
$i.properties.employeeID
$i.properties.cn
$i.properties.mail
}
Après execution du script, le mail et le cn s'affichent mais pas l'employeeID.
Alors que quand je recupere dans le shell directement, sa passe sans problème
$user =[ADSI]"LDAP://*/cn=*,ou=*,OU=*,dc=*dc=*"
$user.get("employeeID")
Pouvez-vous m'aider?
Merci
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
Gilles LAURENT [MVP]
"dav8669" a écrit dans le message de news: | Bonjour,
Bonjour,
| J'ai un problème avec le script suivant | $ldapQuery = "(&(objectclass=user))"
Un objet Ordinateur Active Directory est également membre de la classe "user". Le filtre ci-dessous vous permettra d'obtenir uniquement les propriétés des utilisateurs lors de la requête LDAP : $ldapQuery = "(&(objectCategory=person)(objectClass=user))"
Résolution : Les propriétés de l'objet sont sensibles à la casse :
$i.properties.employeeid
ou alors :
$i.properties.item('EmPloYeeID')
=> Testé sur V1.0 et CTP2
| Après execution du script, le mail et le cn s'affichent mais pas | l'employeeID. Alors que quand je recupere dans le shell directement, | sa passe sans problème $user =[ADSI]"LDAP://*/cn=*,ou=*,OU=*,dc=*dc=*" | $user.get("employeeID")
Je vous l'accorde, cela n'est pas très cohérent. Je jette un oeil sur "MS Connect" dans le cas ou cette information ne soit déjà référencée ... Dans la négative, je remonte l'information au Team PowerShell.
Merci de votre retour.
-- Gilles LAURENT MVP Windows Server - Admin Frameworks http://glsft.free.fr
"dav8669" <dav8669@domain-xyz.in> a écrit dans le message de
news:8eWdnaoTzokakNTURVn_vwA@giganews.com
| Bonjour,
Bonjour,
| J'ai un problème avec le script suivant
| $ldapQuery = "(&(objectclass=user))"
Un objet Ordinateur Active Directory est également membre de la classe
"user". Le filtre ci-dessous vous permettra d'obtenir uniquement les
propriétés des utilisateurs lors de la requête LDAP :
$ldapQuery = "(&(objectCategory=person)(objectClass=user))"
Résolution :
Les propriétés de l'objet sont sensibles à la casse :
$i.properties.employeeid
ou alors :
$i.properties.item('EmPloYeeID')
=> Testé sur V1.0 et CTP2
| Après execution du script, le mail et le cn s'affichent mais pas
| l'employeeID. Alors que quand je recupere dans le shell directement,
| sa passe sans problème $user =[ADSI]"LDAP://*/cn=*,ou=*,OU=*,dc=*dc=*"
| $user.get("employeeID")
Je vous l'accorde, cela n'est pas très cohérent. Je jette un oeil sur
"MS Connect" dans le cas ou cette information ne soit déjà référencée
... Dans la négative, je remonte l'information au Team PowerShell.
Merci de votre retour.
--
Gilles LAURENT
MVP Windows Server - Admin Frameworks
http://glsft.free.fr
"dav8669" a écrit dans le message de news: | Bonjour,
Bonjour,
| J'ai un problème avec le script suivant | $ldapQuery = "(&(objectclass=user))"
Un objet Ordinateur Active Directory est également membre de la classe "user". Le filtre ci-dessous vous permettra d'obtenir uniquement les propriétés des utilisateurs lors de la requête LDAP : $ldapQuery = "(&(objectCategory=person)(objectClass=user))"
Résolution : Les propriétés de l'objet sont sensibles à la casse :
$i.properties.employeeid
ou alors :
$i.properties.item('EmPloYeeID')
=> Testé sur V1.0 et CTP2
| Après execution du script, le mail et le cn s'affichent mais pas | l'employeeID. Alors que quand je recupere dans le shell directement, | sa passe sans problème $user =[ADSI]"LDAP://*/cn=*,ou=*,OU=*,dc=*dc=*" | $user.get("employeeID")
Je vous l'accorde, cela n'est pas très cohérent. Je jette un oeil sur "MS Connect" dans le cas ou cette information ne soit déjà référencée ... Dans la négative, je remonte l'information au Team PowerShell.
Merci de votre retour.
-- Gilles LAURENT MVP Windows Server - Admin Frameworks http://glsft.free.fr
Emmanuel Dreux
Bonjour,
cet attribut ne doit pas faire partie de la liste des attributs retournés par défaut par l'AD. Il faut demander à LDAP de le retourner explicitement.
Bonjour, J'ai un problème avec le script suivant $ldapQuery = "(&(objectclass=user))" $de = [ADSI]"LDAP://*.*.*.*/ou=*,OU=*,dc=*,dc=*" $ads = new-object system.directoryservices.directorysearcher -argumentlist $de,$ldapQuery $complist = $ads.findall() foreach ($i in $complist) { $i.properties.employeeID $i.properties.cn $i.properties.mail } Après execution du script, le mail et le cn s'affichent mais pas l'employeeID. Alors que quand je recupere dans le shell directement, sa passe sans problème $user =[ADSI]"LDAP://*/cn=*,ou=*,OU=*,dc=*dc=*" $user.get("employeeID") Pouvez-vous m'aider? Merci
Bonjour,
cet attribut ne doit pas faire partie de la liste des attributs retournés
par défaut par l'AD.
Il faut demander à LDAP de le retourner explicitement.
Bonjour,
J'ai un problème avec le script suivant
$ldapQuery = "(&(objectclass=user))"
$de = [ADSI]"LDAP://*.*.*.*/ou=*,OU=*,dc=*,dc=*"
$ads = new-object system.directoryservices.directorysearcher -argumentlist
$de,$ldapQuery
$complist = $ads.findall()
foreach ($i in $complist) {
$i.properties.employeeID
$i.properties.cn
$i.properties.mail
}
Après execution du script, le mail et le cn s'affichent mais pas l'employeeID.
Alors que quand je recupere dans le shell directement, sa passe sans problème
$user =[ADSI]"LDAP://*/cn=*,ou=*,OU=*,dc=*dc=*"
$user.get("employeeID")
Pouvez-vous m'aider?
Merci
Bonjour, J'ai un problème avec le script suivant $ldapQuery = "(&(objectclass=user))" $de = [ADSI]"LDAP://*.*.*.*/ou=*,OU=*,dc=*,dc=*" $ads = new-object system.directoryservices.directorysearcher -argumentlist $de,$ldapQuery $complist = $ads.findall() foreach ($i in $complist) { $i.properties.employeeID $i.properties.cn $i.properties.mail } Après execution du script, le mail et le cn s'affichent mais pas l'employeeID. Alors que quand je recupere dans le shell directement, sa passe sans problème $user =[ADSI]"LDAP://*/cn=*,ou=*,OU=*,dc=*dc=*" $user.get("employeeID") Pouvez-vous m'aider? Merci
Gilles LAURENT [MVP]
"Emmanuel Dreux" a écrit dans le message de news: | Bonjour,
Bonsoir,
| cet attribut ne doit pas faire partie de la liste des attributs | retournés par défaut par l'AD. [...]
Cet attribut est retourné si celui-ci est renseigné. PS > $user.Properties.ProtertyNames
C'est uniquement un problème lié à la casse (V1 / CTP2)
-- Gilles LAURENT MVP Windows Server - Admin Frameworks http://glsft.free.fr
"Emmanuel Dreux" <EmmanuelDreux@discussions.microsoft.com> a écrit dans
le message de
news:1E858469-FEB1-47B6-8A9A-D2AE95C2E15E@microsoft.com
| Bonjour,
Bonsoir,
| cet attribut ne doit pas faire partie de la liste des attributs
| retournés par défaut par l'AD.
[...]
Cet attribut est retourné si celui-ci est renseigné.
PS > $user.Properties.ProtertyNames
C'est uniquement un problème lié à la casse (V1 / CTP2)
--
Gilles LAURENT
MVP Windows Server - Admin Frameworks
http://glsft.free.fr
"Emmanuel Dreux" a écrit dans le message de news: | Bonjour,
Bonsoir,
| cet attribut ne doit pas faire partie de la liste des attributs | retournés par défaut par l'AD. [...]
Cet attribut est retourné si celui-ci est renseigné. PS > $user.Properties.ProtertyNames
C'est uniquement un problème lié à la casse (V1 / CTP2)
-- Gilles LAURENT MVP Windows Server - Admin Frameworks http://glsft.free.fr
Emmanuel Dreux
Bonjour,
effectivement,il est retourné par défaut même s'il n'est pas explicitement spécifié. Je n'avais pas d'AD sous la main au moment ou j'ai fais le POST précédent.
Curieux et bug de cette version de powershell que de rendre sensible à la casse un nom d'attribut!!! bien vu :-)
ADSI et LDAP ne sont pas sensible à la casse ( sauf le nom du provider ex LDAP://). J'ai vérifié dans un langage classique et une recherche sur LDAP://ou=monou,dc=mondom,dc=com ou sur LDAP://OU=MONOU,DC=MONDOM,DC=COM retournent tous 2 les mêmes objets.
De même, directoryentry.Properties["employeeid"].Value et directoryentry.Properties["EmployeeID"].Value retournent tous 2 la valeur.
"Emmanuel Dreux" a écrit dans le message de news: | Bonjour,
Bonsoir,
| cet attribut ne doit pas faire partie de la liste des attributs | retournés par défaut par l'AD. [...]
Cet attribut est retourné si celui-ci est renseigné. PS > $user.Properties.ProtertyNames
C'est uniquement un problème lié à la casse (V1 / CTP2)
-- Gilles LAURENT MVP Windows Server - Admin Frameworks http://glsft.free.fr
Bonjour,
effectivement,il est retourné par défaut même s'il n'est pas explicitement
spécifié.
Je n'avais pas d'AD sous la main au moment ou j'ai fais le POST précédent.
Curieux et bug de cette version de powershell que de rendre sensible à la
casse un nom d'attribut!!!
bien vu :-)
ADSI et LDAP ne sont pas sensible à la casse ( sauf le nom du provider ex
LDAP://).
J'ai vérifié dans un langage classique et une recherche sur
LDAP://ou=monou,dc=mondom,dc=com ou sur LDAP://OU=MONOU,DC=MONDOM,DC=COM
retournent tous 2 les mêmes objets.
De même,
directoryentry.Properties["employeeid"].Value et
directoryentry.Properties["EmployeeID"].Value retournent tous 2 la valeur.
"Emmanuel Dreux" <EmmanuelDreux@discussions.microsoft.com> a écrit dans
le message de
news:1E858469-FEB1-47B6-8A9A-D2AE95C2E15E@microsoft.com
| Bonjour,
Bonsoir,
| cet attribut ne doit pas faire partie de la liste des attributs
| retournés par défaut par l'AD.
[...]
Cet attribut est retourné si celui-ci est renseigné.
PS > $user.Properties.ProtertyNames
C'est uniquement un problème lié à la casse (V1 / CTP2)
--
Gilles LAURENT
MVP Windows Server - Admin Frameworks
http://glsft.free.fr
effectivement,il est retourné par défaut même s'il n'est pas explicitement spécifié. Je n'avais pas d'AD sous la main au moment ou j'ai fais le POST précédent.
Curieux et bug de cette version de powershell que de rendre sensible à la casse un nom d'attribut!!! bien vu :-)
ADSI et LDAP ne sont pas sensible à la casse ( sauf le nom du provider ex LDAP://). J'ai vérifié dans un langage classique et une recherche sur LDAP://ou=monou,dc=mondom,dc=com ou sur LDAP://OU=MONOU,DC=MONDOM,DC=COM retournent tous 2 les mêmes objets.
De même, directoryentry.Properties["employeeid"].Value et directoryentry.Properties["EmployeeID"].Value retournent tous 2 la valeur.
"Emmanuel Dreux" a écrit dans le message de news: | Bonjour,
Bonsoir,
| cet attribut ne doit pas faire partie de la liste des attributs | retournés par défaut par l'AD. [...]
Cet attribut est retourné si celui-ci est renseigné. PS > $user.Properties.ProtertyNames
C'est uniquement un problème lié à la casse (V1 / CTP2)
-- Gilles LAURENT MVP Windows Server - Admin Frameworks http://glsft.free.fr
Gilles LAURENT [MVP]
"Emmanuel Dreux" wrote:
Bonjour,
Bonjour Emmanuel
effectivement,il est retourné par défaut même s'il n'est pas explicitement spécifié. Je n'avais pas d'AD sous la main au moment ou j'ai fais le POST précédent.
Curieux et bug de cette version de powershell que de rendre sensible à la casse un nom d'attribut!!! bien vu :-)
[...]
Vu la qualité de vos réponses dans les autres forums et plus particulièrement ceux de Windows Server, je vous pardonne bien volontier :-) Errare humanum est !
-- Gilles LAURENT MVP Windows Server - Admin Frameworks http://glsft.free.fr
"Emmanuel Dreux" wrote:
Bonjour,
Bonjour Emmanuel
effectivement,il est retourné par défaut même s'il n'est pas explicitement
spécifié.
Je n'avais pas d'AD sous la main au moment ou j'ai fais le POST précédent.
Curieux et bug de cette version de powershell que de rendre sensible à la
casse un nom d'attribut!!!
bien vu :-)
[...]
Vu la qualité de vos réponses dans les autres forums et plus
particulièrement ceux de Windows Server, je vous pardonne bien volontier :-)
Errare humanum est !
--
Gilles LAURENT
MVP Windows Server - Admin Frameworks
http://glsft.free.fr
effectivement,il est retourné par défaut même s'il n'est pas explicitement spécifié. Je n'avais pas d'AD sous la main au moment ou j'ai fais le POST précédent.
Curieux et bug de cette version de powershell que de rendre sensible à la casse un nom d'attribut!!! bien vu :-)
[...]
Vu la qualité de vos réponses dans les autres forums et plus particulièrement ceux de Windows Server, je vous pardonne bien volontier :-) Errare humanum est !
-- Gilles LAURENT MVP Windows Server - Admin Frameworks http://glsft.free.fr
