0
votes

Encapsuleur de script d'installation Powershell basé sur l'unité d'organisation

Merci beaucoup pour votre temps avant de lire ceci (ça va être une longue question).

Je suis un débutant avec un peu de connaissance de Powershell. J'ai une situation dans laquelle je crée un script d'encapsulation d'installation.

Ce script sera exécuté sur de nombreuses machines utilisateur, et ils peuvent / peuvent ne pas avoir accès à Active Directory.

Mais le script doit être tel que, si l'objet Machine fait partie d'une UO spécifique dans Active Directory, il doit choisir le fichier de configuration en conséquence.

Les informations de l'UO seront-elles stockées quelque part dans le WMI? Qu'est-ce que le moteur de recherche ADSI, aura-t-il besoin d'un accès spécial ou de pré-requis pour fonctionner correctement?

J'ai recherché sur Google et obtenu le script ci-dessous en utilisant ADSI et il semble fonctionner sur ma machine virtuelle, mais pas sur quelques autres machines virtuelles (pour des raisons que je ne connais pas).

 Path                                                        Properties
----                                                        ----------
LDAP://CN=,OU=< ........>,OU=V< ...>,OU=N... {primarygroupid, iscriticalsystemobject, msds-supportede...

J'ai essayé d'exécuter le script sur diverses autres machines utilisateur (niveaux d'accès AD mixtes), et $ OU = $ ($ Computer.Properties.Item ('distingué')) génère une erreur.

Vous ne pouvez pas appeler une méthode sur une expression à valeur nulle. À la ligne: 1 car: 42 + $ OU = $ ($ Computer.Properties.Item

Mais $ computer n'est pas une valeur nulle. Il a le résultat ci-dessous (j'ai modifié les informations LDAP ..)

$ComputerName = $env:ComputerName

$ADSISearcher = New-Object System.DirectoryServices.DirectorySearcher

$ADSISearcher.Filter = '(&(name=' + $ComputerName + ')(objectClass=computer))'

$ADSISearcher.SearchScope = 'Subtree'

$Computer = $ADSISearcher.FindAll()

$OU = $($Computer.Properties.Item('distinguishedName'))

Maintenant, la question est: Suis-je dans la bonne direction, le chercheur ADSI interrogera-t-il ces informations localement informations mises en cache?

Si oui, pouvez-vous m'aider à résoudre ce problème? Si je me trompe, veuillez me corriger. Je suis assis avec ça depuis des jours maintenant et de l'aide serait très appréciée.


4 commentaires

"si l'objet Machine fait partie d'une OU spécifique dans Active Directory, choisissez le fichier de configuration en conséquence" - Je pense qu'une stratégie de groupe conviendrait mieux. Vous pouvez définir une stratégie de groupe sur chaque unité d'organisation qui exécute un script d'ouverture de session différent.


oui .. mais le fichier de configuration est passé à un installateur qui est assez énorme. donc mes clients y sont peu réticents.


Cette erreur indique que $ Computer.Properties.Item est null . Ce n'est pas null pour moi lorsque je l'essaye. Mais vous pouvez accéder au même attribut avec $ Computer.Properties ["distingué"] ... peut-être que cela fonctionne?


Il vaut peut-être mieux utiliser $ ADSISearcher.FindOne () ou parcourir les résultats renvoyés par $ ADSISearcher.FindAll ()


3 Réponses :


0
votes

Y a-t-il une chance que les machines sur lesquelles vous testez ne soient pas jointes au domaine?

Quoi qu'il en soit, même si je vous recommande de choisir une solution différente autre que le chemin que vous empruntez, ce code fonctionne-t-il mieux pour vous? Notez également que vous avez mentionné que les contrôleurs de domaine peuvent ou non être joignables. Si tel est le cas, cette requête échouera à partir de la machine locale (et la récupération de la stratégie de groupe à partir de sysvol le ferait également).

$LDAPDN = ([adsisearcher]"(&(name=$env:computername)(objectClass=computer))").findall().path

If ($LDAPDN) {
    $OU = $LDAPDN.Replace("LDAP://CN=$env:computername,","")
}

Else {
    Write-Warning "Unable to find $env:computername in AD or the adsi search failed"
}


1 commentaires

Merci beaucoup pour votre temps précieux et votre code. et j'ai essayé votre code, j'ai reçu le message d'avertissement que vous avez présenté. Mais je suis sûr que la machine est dans Vcenter et qu'il n'y aurait pas de problème de connexion. Mais comme vous l'avez suggéré, je commence à réfléchir à d'autres solutions possibles. Merci encore pour votre aide ici à ce sujet.



0
votes

J'ai pu reproduire cela si vous l'exécutez avec un compte d'utilisateur qui ne figure pas sur le même domaine que l'ordinateur. Il essaie de rechercher le domaine de l'utilisateur, puis ne trouve pas l'ordinateur. Vous devez donc le dire spécifiquement de se connecter au domaine de l'ordinateur, que vous pouvez trouver à l'aide de: xxx

Il existe également des formes courtes que vous pouvez utiliser, comme [ADSI] et [ADSISISEARCHER] Pour rendre le code plus succinct.

Le répertoire (code> (AKA [adsisearch] ) Utilisé ici est le fichier DirectorySearcher , qui fait partie de la structure .NET et sera installé par défaut dans Windows. Donc, vous n'avez pas à vous soucier de ne pas être disponible. Mais l'ordinateur doit être connecté au réseau pour que cela fonctionne. xxx

Notez que le Searchroot est défini sur le domaine de l'ordinateur. < / p>

le searchScope est sous-arbree Par défaut, vous n'avez donc pas besoin de définir cela.

C'est une bonne idée d'utiliser propriétéToLoad pour le dire quels attributs vous voulez que cela revienne. Sinon, il retournera tous les attributs avec une valeur. Cela ne fera probablement pas une grande différence ici, mais cela peut dans d'autres cas.

i a également utilisé figurine () , qui renvoie une valeur unique, au lieu de Retrouver () , qui renvoie un tableau. Vraiment, il ne devrait y avoir qu'un seul résultat, c'est pourquoi vous pouvez traiter la matrice comme si ce n'était pas.

Notez que l'attribut distinguée est le chemin complet de la objet, pas seulement l'ou. Donc, si vous voulez l'ou, vous devez extraire cette partie du distinguéeName , ce que j'ai fait ici. (Tous les attributs sont présentés comme des tableaux, c'est pourquoi vous avez besoin de [0] là)


3 commentaires

Merci beaucoup de m'aider à comprendre. J'ai essayé votre script sur l'une des machines défaillantes et malheureux que j'ai échoué pour la même raison


$ DN = $ Computer.Properties ["distingué"] [0] Impossible d'indexer dans un tableau nul. À la ligne: 1 car: 49 + $ DN = $ Computer.Properties ["distingué"] [<<<< 0] + CategoryInfo: InvalidOperation: (0: Int32) [], RuntimeException + FullyQualifiedErrorId: NullArray


Oui c'est l'erreur. Trouver on réussit. et même $ ordinateur a la recherche valories.ps c: \ users \ adoss> $ Propriétés du chemin d'ordinateur ----------------------------- / CN = , OU = ... {distinguéeName, adspath}



0
votes

Merci beaucoup de m'aider aujourd'hui! J'ai certainement appris beaucoup d'informations. J'ai fait demi-tour et je regardais par un autre itinéraire (certainement une requête très lente par rapport à ADSI). Mais travaille sur des scénarios interdomaines. Réf: Comment utiliser WMI pour obtenir l'unité d'organisation actuelle d'un ordinateur et répertorier tous les autres ordinateurs de cette unité d'organisation?

$ComputerName = $env:ComputerName;
$Computer = Get-WmiObject -Namespace 'root\directory\ldap' -Query "Select DS_distinguishedName from DS_computer where DS_cn = '$ComputerName'";
$OU = $Computer.DS_distinguishedName.Substring($Computer.DS_distinguishedName.IndexOf('OU='));

a obtenu le résultat souhaité de toutes mes VM de test


0 commentaires