All the information on how to use the module is included in the previous post, so I wont re-invent the wheel. Have a read of the previous post for any caveats or pre-emptive misunderstandings.

Below are two code snippets to use OU membership with either the Quest or Microsoft cmdlets for active directory, just modify the OU Path below, I’ve tried to include a long example to ensure there’s no confusion.

 Quest Active directory Snap-in:

[sourcecode language=”Powershell”]
#Quest Active directory module
import-module "C:citrix.edgesight.cmdlets.psm1"
add-pssnapin Quest.ActiveRoles.ADManagement
$ADOU=’domain.domain.com/Country/Users/advanced/Helpdesk’
$esgroupid=20

#clear the group before import
clear-esgroupmembers -groupid $esgroupid

#get users from group, then import them into edgesight
foreach ($user in get-QADUser -SearchRoot $ADOU -SizeLimit 0){
$prid = get-ESUserPrid $user.logonname
if ($prid -NE $null){
Add-ESGroupMember -groupid $ESgroupid -prid $prid
}
}#end For
[/sourcecode]

Microsoft Active directory module:

[sourcecode language=”Powershell”]
#Microsoft active directory module
import-module "C:citrix.edgesight.cmdlets.psm1"
import-module activedirectory
$ADOU="OU=helpdesk,OU=advanced,OU=Users,OU=Country,DC=domain,DC=domain,DC=com"
$esgroupid=20

#clear the group before import
clear-esgroupmembers -groupid $esgroupid

#get users from group, then import them into edgesight
foreach ($user in get-ADUser -filter * -searchbase $ADOU){
$prid = get-ESUserPrid $user.samaccountname
if ($prid -NE $null){
Add-ESGroupMember -groupid $ESgroupid -prid $prid
}
}#end For
[/sourcecode]

The script is fairly self explanatory but quite scary if you get it wrong, for that reason I’ve included the -whatif parameter to show you what will happen if you overzealously just copy and paste the code. Once you are happy it works, remove the whatif parameters.

This script relies on the powershell module for active directory, you can see if its installed as below:

I’m also aware this code is quite inefficient by searching twice, but it was the cleanest appearance I could muster to ensure the end user understands what is happening.

[sourcecode language=”Powershell”]

#Load the required Snapins
if (!(import-module "activedirectory" -ea 0)) {
Write-Host "Loading active directory module." -ForegroundColor Yellow
import-module "activedirectory" -ea Stop
}#endif

#users
foreach ($user in search-adaccount -UsersOnly -AccountInactive -TimeSpan 90.00:00:00){
move-adobject -identity $user.DistinguishedName -targetpath "OU=Old Users,DC=some,DC=domain,dc=net" -whatif
}

#computers
foreach ($computer in search-adaccount -Computersonly -AccountInactive -TimeSpan 90.00:00:00){
move-adobject -identity $computer.DistinguishedName -targetpath "OU=Old Computers,DC=some,DC=domain,dc=net" -whatif
}
[/sourcecode]

Edgesight doesn’t seem to have any API’s or command line interfaces to hook into. For this reason my scripts are based on connecting to the Edgesight database and retrieving the information with SQL statements. This presented a really fun challenge for me as I’m an SQL novice. I learned quite a bit in a short period of time by writing this powershell module.

With the following module you can run scheduled tasks to connect to your edgesight database and add / amend your user groups with ease.

First, some caveats, warnings and limitations of Edgesight you should be aware of:

• My SQL statements have been tested fully internally and work flawlessly, that being said Always backup your database before you attempt to use these modules.
• Each Edgesight group has a unique GUID assigned when it is created, for this reason you must manually create the Edgesight groups before attempting to import users.
• Each user has a unique identifier in Edgesight called a PRID, if Edgesight has not seen a user before, the PRID will not exist. As such, you cannot import a user who has not logged into the environment before.

The Module:



I have sealed the necessary commands for this job into a self contained module you can import on runtime.

The module needs to be edited by hand before you first use it. This is to specify the credentials you wish to use to connect to the Edgesight database.  I have included options for trusted connections and SQL account logins. For more information on this read the Configuring the module section below.



Module Components:

This module has the following commands embedded to be used as part of your maintenance scripts:

Get-ESGroups

• Retrieves the name and ID of each Edgesight user group

Get-ESGroupMembers

• Retrieves all members PRID’s of a specified user group.

Add-ESGoupMember

• Ensures the user isnt already in the group.
• Adds a specified user to a specified group.

Remove-ESGroupMember

• Remove a user via their prid from a specified user group.

Clear-ESGroupMembers

• Removes all members from the specified group.
• Reports the amount of users removed.

Get-ESUserPrid

• Looks up a user by name (samaccount name / login name) and returns their Prid.
• Warns if the user doesn’t exist.

Get-ESUserName

• Looks up a user by Prid and returns their login name.
• Warns if the user doesn’t exist.

Dowloading the module:



You can download the Edgesight Module from my box.net account here. Remember to continue down this blog post to see how to use the modules for your best chance of success.



Configuring the module:



Once you have downloaded the module, you need to edit it by hand before you first use it. This is to specify the credentials you wish to use to connect to the Edgesight database.

Configuring the SQL Server and database name:

• Change the $SQLServer variable (labeled 1: below) to the sql database server or instance name you wish to connect to.
• Change the $SQLDatabase variable (labeled 2: below) to the sql database name you wish to connect to.:



Below is an example of how this should look:

Configuring the SQL login details:



I have included options for trusted connections and SQL account logins. Here’s a brief description of the two options available to you when configuring your authentication for this module:

• A trusted connection is a connection using your logged in details.
• A non trusted connection requires a SQL user account and password with modify rights to the edgesight database.

Using a Trusted connection:

• Configure the $SQLTrustedConnection variable as $true
• You can then ignore or remove the $SQLUsername and $SQLpassword variables.

An example of how this should appear is below:

Using an untrusted connection:

• Configure the $SqlTrustedConnection variable ( labelled below as 1:) as $false
• Configure the $SqlUserName variable as the SQL username labelled below as 2:) with the afforementioned access rights.
• Configure the $SQLPassword variable as the SQL user’s password (labelled below as 3:)

Note: remember to wrap the username and password in quotes.

An example of how this should appear is below:

Once you’ve configured the Module to suit your environment, simply save it.



Importing the Module:



Once you’ve modified to module to suit yourselves, its time to import the module and see if you’ve configured it correctly.

I suggest you change  your executionpolicy to unrestricted with the following command first to remove any overzealous security warnings:

set-executionpolicy unrestricted

Now, open a powershell window and run the following command: (where c: is the location of the module)



import-module C:Citrix.Edgesight.Cmdlets.psm1

The module will either error out telling you that the details are incorrect as below:

Or confirm a database connection has been established:

If the module imported correctly, try one of my powershell functions to see if you can retrieve information.

For example, try:

get-esgroups

Adding and removing users from groups:



Once we have the module imported, now we can get to the important task of modifying the memberships of edgesight  groups. Lets do this manually once so we understand the process for active directory imports later.

1: To retrieve an Edgesight user Group’s group ID, run the following command:

get-esgroups

For this article, we’ll assume we want to add users to “All Access Gateway Users”, so the groupid is 11.

2: To clear the group, we can use the following command:

Clear-ESgroupmembers -GroupID 11

The command should return the amount of deleted users



3: Because we need the Edgesight user’s PRID to add the member to the group, we can achieve that by running the following command: (where “user” is the users name is the login name)

Get-ESUserPrid username

I’ve omitted the username for privacy reasons.



4: Once we have the PRID we can now add the user to the group:

add-esgroupmember -GroupID 11 -Prid 26

If this returns no error, this has completed successfully



5: To confirm this user is now in the correct group, try:

get-esgroupmembers -GroupID 11

You should see you user added as above.



You can also check this in Edgesight by reviewing the group details:

I’ve omitted the username for privacy reasons.



So now that we know a single user import works, lets try an active directory import.



Importing from Active Directory:

you will need the following items for this task:

• a Powershell module or snapin for listing members of groups. *
• The active directory name group.
• The GroupID you wish to add the users to.

The basic concept behind this task, is to clear the current group then repopulate it with users from AD. Above I’ve walked you through one user, so now you understand the concept and can modify the script to import in bulk safe in the knowledge you know what is happening.

Now that you understand the process, its just a matter of using a powershell snapin or module to list active directory users and import them one by one.

Below you will find two examples using the quest and microsoft tools. These are fairly basic examples as each persons needs are different, the module is robust and flexible enough for you to script your own solution using these modules and I’ll happily help if you have a specific requirement not covered by these basic examples.

*In reference to the powershell module, they are numerous and available online, for the sake of completeness I’ve included the Quest tools & the Microsoft ActiveDirectory module below for reference.



Quest Active Directory Snapin:

Below you will find an example on how to use the Quest active directory snapin for powershell to retrieve users from the group “Active directory user group” and populate the Edgesight user group 20 with these members.

For convenience, you can download this here:

[sourcecode language=”PowerShell”]
import-module "C:citrix.edgesight.cmdlets.psm1"
add-pssnapin Quest.ActiveRoles.ADManagement
$group="Active Directory User Group"
$esgroupid=20

#clear the group before import
clear-esgroupmembers -groupid $esgroupid

#get users from group, then import them into edgesight
foreach ($user in Get-QADGroupMember $group -type user -indirect -sizelimit 0){
$prid = get-ESUserPrid $user.logonname
if ($prid -NE $null){
Add-ESGroupMember -groupid $ESgroupid -prid $prid
}
}#end For
[/sourcecode]

Microsoft ActiveDirectory Powershell module:

Below you will find an example on how to use the Microsoft ActiveDirectory module for powershell to retrieve users from the group “Active directory user group” and populate the Edgesight user group 20 with these members.

For convenience, you can download this here:

[sourcecode language=”PowerShell”]
import-module "C:citrix.edgesight.cmdlets.psm1"
import-module activedirectory
$group="Active Directory User Group"
$esgroupid=20

#clear the group before import
clear-esgroupmembers -groupid $esgroupid

#get users from group, then import them into edgesight
foreach ($user in Get-ADGroupMember $group -recursive){
$prid = get-ESUserPrid $user.samaccountname
if ($prid -NE $null){
Add-ESGroupMember -groupid $ESgroupid -prid $prid
}
}#end For
[/sourcecode]

Keeping your groups up to date:

Once you are happy that you have gotten the code to work for your environment, you can simply run these scripts as scheduled tasks and the groups will be cleared and repopulated when the scheduled task runs.

It’s that simple.

Getting further help with these modules:



Once the module is imported, you can retrieve help on any of these commands by running “get-help (command)”, where command is the command you wish to retrieve help from.

I’m also quite happy to support and expand this module is necessary as I really enjoyed this project. Drop me a comment or email: andrew (at) andrewmorgan (dot) ie and I’ll see if I can help you with this.

I used dsget to pull the user information from the group, below is the command i used:

dsget group “cn=Groupname,ou=DLs,ou=Exchange Recipients,dc=ie,dc=domain,dc=company,dc=com” -members >> 1.txt

the above command enumerates the “groupname” group in an ou called dls, in an ou called exchange recipients in the domain ie.domain.company.com. if your ou or domain structure is different trim out (or add) what you need.  The -members at the end of the file will dump only the usernames in FQDN format.

Once the script is run check the current directory for a textfile called 1.txt.  This text file will contain the usernames you need in FQDN format like below:

“CN=Tom Thumb (IE),ou=Dublin,dc=ie,dc=domain,dc=company,dc=com”
“CN=Mike Hunt (IE),ou=Dublin,dc=ie,dc=domain,dc=company,dc=com”

In order to get the email address’es i decided not to try and read from the file, instead i just ran the same command again and piped the results to another dsget query.

dsget group “cn=Groupname,ou=DLs,ou=Exchange Recipients,dc=ie,dc=domain,dc=company,dc=com” -members | dsget user -email >> 2.txt

The above will pull the results we saw in 1.txt, but instead it passes it straight into another query (dsget user -email) and sends those results to a text file. 2.txt should contain the users primary email address:

tom.thumb@company.com
mike.hunt@company.ie

Now simply copy the contents on both text files into neighboring columns in excel and you have your report

Update: 13/08/2012

An old friend of mine Rob reminded me that this post existed and wondered how to do it with powershell. Luckily This is much, much easier to do with Windows Powershell!

On a server with the active directory module for powershell installed (normally a domain controller), run the following commands: (replace the group name with your own one).

[sourcecode language=”PowerShell”]

#######Change the below values#######
$groupname = "My Group Name"
$exportfile = c:tempreport.csv
#####################################

if (!(get-module -ListAvailable | where {$_.name -eq "ActiveDirectory1"} -ea 0)){
write-warning "The ActiveDirectory PowerShell module is Not Installed!"
break}
else{
write-host "Importing Active directory module";import-module activedirectory -ea 0
Get-ADGroupmember $groupname | %{get-aduser $_.samaccountname -properties cn,samaccountname,emailaddress | select cn,samaccountname,emailaddress | export-csv -notypeinformation $exportfile}
}
[/sourcecode]

Update: With thanks to some great help and troubleshooting from Steven we have resolved the line 46 “Categor” error. In order for the adm to parse the ending y in this file an additional two blank lines or “carriage returns” are necessary at the base of the adm file. The download file has been updated, Thanks again Steven.

A .adm file, is a group policy file that specifies policies outside of Microsoft’s default options. Basically they are policies you can put in place that Microsoft in their infinite wisdom forgot to put in before launch.

I had a situation recently where we have external users coming into our network, and using our CAG’s to access the the citrix environment. Once in there they needed access to an internal webpage that we published with internet explorer. The problem therein lied that these users could browse the local lan for resources with the address bar and many other wonderful utilities Microsoft put into internet explorer but failed to lock down efficiently.

All i really cared about (and for the interest of this post) was locking down the address bar in Internet Explorer 6.1. Nowhere could i find an option to do this, and i was getting nowhere fast. Searching internet explorer did bring back a few “helpful” articles on technet that i just couldnt understand, and i did find a piece of software that used to do it for free, until microsoft bought the company, stole its code for server 2008 and stopped people using or downloading the application. nice one microsoft…

I have attached the policy settings and ADM files for reference on how to lock down internet explorer 6 completely, hopefully i will save somebody else 7 hours of their time.

Long story short, no policy existed, no helpful application and because i needed this policy to only affect the users (and not the servers where internal staff use internet explorer too) i had to create the adm file myself.

I opened the word2003 adm file you get with ork 2003 and set about bodgeing the code to suit myself, The below entries disable the address and link bars by using registry entries. Remember you must still lock the toolbar in group policy to restrict these users from changing the tool bars.

CLASS USER

CATEGORY “Internet Explorer Lockdown”
KEYNAME “SoftwarePoliciesMicrosoftInternet ExplorerToolbarsRestrictions”
POLICY “Disable internet explorer address bar”
PART “Check to enforce setting on; uncheck to enforce setting off” CHECKBOX
VALUENAME NoAddressBar
VALUEON NUMERIC 1
VALUEOFF NUMERIC 0
END PART
END POLICY
POLICY “Disables internet explorer links bar”
PART “Check to enforce setting on; uncheck to enforce setting off” CHECKBOX
VALUENAME NoLinksBar
VALUEON NUMERIC 1
VALUEOFF NUMERIC 0
END PART
END POLICY
END CATEGORY

and to disable the other lockdowns i required (not covered in group policy…./sigh) disabling the search function, disabling the help bar and disabling mail/news are listed below.

CATEGORY “Internet Explorer Lockdown”
KEYNAME “SoftwarePoliciesMicrosoftInternet ExplorerRestrictions”
POLICY “Disable internet explorer help bar”
PART “Check to enforce setting on; uncheck to enforce setting off” CHECKBOX
VALUENAME NoHelpMenu
VALUEON NUMERIC 1
VALUEOFF NUMERIC 0
END PART
END POLICY
POLICY “Disable Mail&News option”
PART “Check to enforce setting on; uncheck to enforce setting off” CHECKBOX
VALUENAME RestGoMenu
VALUEON NUMERIC 1
VALUEOFF NUMERIC 0
END PART
END POLICY
END CATEGORY
CATEGORY “Internet Explorer Lockdown”
KEYNAME “SoftwareMicrosoftWindowsCurrentVersionPoliciesexplorer”
POLICY “Disable Search Access”
PART “Check to enforce setting on; uncheck to enforce setting off” CHECKBOX
VALUENAME NoFind
VALUEON NUMERIC 1
VALUEOFF NUMERIC 0
END PART
END POLICY
END CATEGORY

Once i had the above all in one text document, saved it as a .adm file and imported it into group policy. Checked the options and hey presto, users were locked down. It took me over 8 hours to achieve the above (and the other default policy settings) realistically it shouldn’t have taken more than 2.

Files are here: