none
Login Script Issue using Switch

    Question

  • Hi, I want to re-write a very long an unwieldy VBScript with Powershell.

    Here is the issue: The user groups that relate to drive mappings all have '-MAP' in the groupname with a comma-separated 'notes' field with the drive letter and the share it maps to. I'd ideally like to translate this to GPPreferences but given there are over 300 such groups, that maybe asking too much. Anyway, I'm v. new to PS and I'm clearly missing something syntactically trying to recreate this. Here is my code:

    ([System.Security.Principal.WindowsIdentity]::GetCurrent()).Groups | ForEach-Object {$a = $_.Translate([System.Security.Principal.NTAccount])|

    switch -wildcard ($a) {
         "*-MAP*" { Write-Host 'Found -MAP' }
    }}

    However I get the rror message : Unexpected token '{' in expression or statement.

    A quick explanation if it's needed: First finds the current user logging on and $a is supposed to be assesed as to whether "-MAP" appears in the name of the group.

    As far as I can tell all the braces are there and where they should be. What am I doing wrong?

    samedi 3 mars 2012 10:54

Réponses

  • Try it like this.  Note, that when using Foreach-Object, we need to work with the $_ variable in a script-block.

    ([System.Security.Principal.WindowsIdentity]::GetCurrent()).Groups | `
        ForEach-Object {$_.Translate([System.Security.Principal.NTAccount])} | `
        ForEach-Object { if ($_.value -like '*-MAP*') { Write-Host 'Found -MAP' }}


    Grant Ward, a.k.a. Bigteddy

    What's new in Powershell 3.0 (Technet Wiki)


    • Modifié Bigteddy samedi 3 mars 2012 11:09
    • Marqué comme réponse bondy666 samedi 3 mars 2012 11:15
    samedi 3 mars 2012 11:08

Toutes les réponses

  • Try it like this.  Note, that when using Foreach-Object, we need to work with the $_ variable in a script-block.

    ([System.Security.Principal.WindowsIdentity]::GetCurrent()).Groups | `
        ForEach-Object {$_.Translate([System.Security.Principal.NTAccount])} | `
        ForEach-Object { if ($_.value -like '*-MAP*') { Write-Host 'Found -MAP' }}


    Grant Ward, a.k.a. Bigteddy

    What's new in Powershell 3.0 (Technet Wiki)


    • Modifié Bigteddy samedi 3 mars 2012 11:09
    • Marqué comme réponse bondy666 samedi 3 mars 2012 11:15
    samedi 3 mars 2012 11:08
  • Fantastic, thank you for your quick reply.
    samedi 3 mars 2012 11:16
  • It's a pleasure.  Do come again!

    Grant Ward, a.k.a. Bigteddy

    What's new in Powershell 3.0 (Technet Wiki)

    samedi 3 mars 2012 12:01
  • Well since you ask...!

    As a bonus, would you know how to make this recursive?

    samedi 3 mars 2012 12:42
  • Sorry, recursion isn't my strongest point!  Please state in plain language what you are aiming to do.

    Grant Ward, a.k.a. Bigteddy

    What's new in Powershell 3.0 (Technet Wiki)

    samedi 3 mars 2012 15:59
  • Hi BT

    I would like all the nested groups to be checked as well as those on the top level.

    Thanks

    Simon

    samedi 3 mars 2012 21:45
  • Our approach to group-membership based share mappings is a little more along the traditional lines where the relevant group membership in a group associated with the UNC is tested, i.e.:

        if user is in the finance group, map the finance share to F:
        if user is in the personnel group, map the personnel share to P:

    and so on.

    Your approach is rather interesting as it embeds the group/share relationship within active directory rather than in the script itself.

    Unfortunately, both approaches can create significant bottlenecks when used in a logon script.

    Our (vbscript) logon script does not trace group membership with recursive AD calls. Instead it uses IFMEMBER.exe, which determines all group memberships on its first use, as it gets this info from the security token created at logon. Even then a significant amount of time is taken to do this. Another shortcoming is that, due to a fixed size buffer, it fails when the user belongs to more than about 100 groups.

    I did try a recursive approach (with great assistance from others, including Richard Mueller), but found it to be significantly slower.

    I did all my testing at a well-connected location, and found out later that the performance of all of the approaches I tried was poor to abysmal at less well-connected locations (i.e. VPN sites, subnets at locations lacking a DC, and remote access users). In all cases, the IFMEMBER approach was still better than recursive round-trips to a distant DC.

    I submitted a suggestion that the shares to be mapped use permissions so that those not in a group would not be able to even see them. The logon script code would have then changed to something like this:

        if the finance share is visible, map it to F:
        if the personnel share is visible, map it to P:

    Unfortunately, this suggestion was not adopted. It is becoming a moot point, as we are now moving towards share mapping by GPO.

    Note: for those interested, the "recursive" aspect of this thread continues here:

    http://social.technet.microsoft.com/Forums/en/winserverpowershell/thread/c353594a-516c-45c2-8710-db1fcf745702


    Al Dunbar

    dimanche 4 mars 2012 18:07