Skip to main content

UPDATED: AD Sites, Subnets, and Sitelinks Powershell Module

UPDATED: now supports Quest tools see v0.92 update for details


It's been a while since I have put anything on here, as noted by a few of my colleagues. I have been busy developing various ideas in PowerShell, and generally pulling together all the scripts, functions, features, techniques etc that I have learnt over the past few years.  This, and raising an ever growning young family!

It has been a very exciting journey which is far from over, but I suppose I have come to a point where I feel I have something useful to give back.

In my quest to automate AD management (one of the ideas I have been working on), I found that there isn't much in the way of Site / Subnet / Site link management in PowerShell. True, these are just objects in AD and can be referenced by get-ADobject or by the [ADSI] shortcut, or even the quest AD management tools, but formatting the configuration naming context with sub OU's is a pain - if you actually know that this is where sites and services is stored in the first place!

A while back I found the new-xadsite and new-xadsubnet blog posts which, in the end, have inspired this AADSites module. Please note that I have included a couple of the validation functions from new-xadsubnet and accredited them accordingly.

AADSites

The module - my first PowerShell Module - is now in beta (version 0.9). I have tested to the nth degree, but being so close to the subject makes it very difficult to have a completely holistic view of all the options out there. I invite anyone to try it out (in a dev environment first), to see if these functions could help manage your environment and to see what else you would like included.

It is designed to easily create and manage AD Sites, AD subnets and AD Site links within PowerShell. As it is based around the MS AD PowerShell module, it is intended to follow the rules and syntax. For example, when you use new-adobject you have a "-name" parameter whereas get-adobject uses an "-identity" parameter.

Requirements
At present, this module requires the MS AD Management pack. This in itself requires a DC in the Domain that has ADMGS installed (installed by default on a Windows 2008 R2 DC), and a win 7 or 2008 R2 box to run the commands on. If, reading this you are now feeling deflated in the fact that you would like to try this module out but know that there is no way you are going to convince the "owner" of your AD environment to install ADMGS just so you can test "some download", then shout at me in the comments and I will look at doing a new version using the quest tools or ADSI. Also, there are plenty of free VM downloads these days to build up a lab forest on a capable PC - that is incidentally where the entire of this module has been developed.

Installation and use
Download the zip file and extract to your modules folder. This can be found by running "explorer $pshome\modules" from a PowerShell console. To use, run "import-module AADSites"

Command list and Help
To retrieve the list of commands and get help, as with all PowerShell functions and cmdlets use the built in get-command and get-help.

Get-command -module AADSites -type function will list all the commands from the module

Get-help get-AADSite -full will display the full help file

Included functions

The below is a list of the functions available :

Add-AADSiteToSitelink
Confirm-AADSite
Confirm-AADSitelink
Confirm-AADSubnet
Get-AADServicesObject
Get-AADsite
Get-AADsitelink
Get-AADsubnet
Get-IPAddressPrefixLength
Get-NumberOfTrailingZeroes
Move-AADSubnetToSite
New-AADSite
New-AADSiteLink
New-AADSubnet
Remove-AADsite
Remove-AADSiteFromSitelink
Remove-AADsitelink
Remove-AADsubnet
Set-AADSite
Set-AADSitelink
Set-AADSubnet
Test-AADServicesObject

I will be adding the help files for each command to this blog in due course.

Download the module here


cheers

Adam

Comments

Popular posts from this blog

Enable Powershell Remoting (WinRM) via Group Policy

I have been doing some testing on enabling WinRM via group policy, being that WinRM is the service that Powershell v2 sets up it remoting capabilities. Here are the GPO settings that you need to configure WinRM .... set the winrm service to auto start Computer Configuration \ Policies \ Windows Settings \ Security Settings \ System Services Windows Remote Management (WS-Management)  set Startup Mode to Automatic start the service incorporated in to the above - you may need a restart. create a winrm listener Computer Configuration / Policies / Administrative Templates / Windows Components / Windows Remote Management (WinRM) / WinRM Service / Allow automatic configuration of listeners IPv4 filter: * * is listen on all addresses, or if you only want a particular IP address to respond use an iprange eg 10.1.1.1-10.1.1.254 - don't forget that this IP range has to be valid for all hosts that fall in the scope of the GPO you are creating.  You can use 10.1.1.1 -

Assigning Permissions - AGDLP

AGDLP It seems I have been mildly distracted away from the title of this blog site.   It does say AD Admin, but I seem to have been taken away by file system stuff.   I have to say, it has all been worthwhile, but it’s probably time I got back to the real heart of what I do. There are probably a million permission assigning advice pages, but I thought I would put another one out there after referring to AGDLP in my last post. So, what is this all about – AGDLP.   Well, it is something I learned in my MCSE 2003 studies and has become ingrained into my ideals since.   As a contractor, I get to move job often.   This enables me to forge opinions on how to configure things in a domain, and more importantly how NOT to configure things. AGDLP is definitely on the to do list…for anyone in any size domain or forest, as it follows some very basic principals.   I will explain these whilst I go through what AGDPL stands for. A A is for account.   It is the securit

Finding out what 'SearchFlags' are set on you AD attributes

Whilst doing some research into indexed attributes, I posted this  a while back on how to find your index attributes.  Since then, I have looked a little deeper into what indexing really means and found this excellent explanation on the numbers that can be found in the searchflags attribute of a schema object. Using Florian’s reference, I built the following script (which is both powershell v1 and v2 compatible) to get the schema attributes from the forest schema and return (among other things) the breakdown of your attributes search flags. $forest = [System.DirectoryServices.ActiveDirectory.forest]::getcurrentforest() $schema = [ADSI]('LDAP://CN=Schema,CN=Configuration,dc=' + ($($forest).name -replace "[.]",",dc=")) $attributes = $schema.psbase.children | where {$_.objectClass -eq "attributeSchema"} $collection = @() foreach ($attr in $attributes){ $store = "" | select "Name","lDAPDisplayName","singlev