Lead, Follow, or Move » PowerShell

First look at MDT 2010 Beta 2

Adam Bell — Wed, 01 Jul 2009 14:56:15 +0000

Michael has been firing out a lot posts about the new features of MDT 2010 recently, and as this is a tool I do quite a lot with I figured it was time to start playing :)

I have a test server with the Beta 1 MDT 2010 already installed. I wanted to see if any issues are encountered if I just installed over the top.

The installation process didn’t notify me of any previous version, but it selected the installation directory of the existing MDT. I let it install to the same location, and it completed without any errors.

The new and improved workbench.

I like the new shiny icons, but more importantly I like how I can organise things in folders :)

My existing MDT items were all still available, with the exception of the deployment share. Selecting to open an existing share and selecting the upgrade check box appears to have brought everything up to date.

Property page has been updated

One of my minor annoyances for a long time has been resolved. You can now tab through the fields, though you have to tab through both sides *grrr*.

From a PowerShell perspective a quick look reveals that we have one snapin to play with: microsoft.bdd.PSsnapin.

The PowerShell Snapin for MDT 2010

16 cmdlets are provided by the MDT snapin

I haven’t played with these yet, but they look to be promising.

News and Events

Adam Bell — Mon, 29 Jun 2009 15:22:24 +0000

The Summer Scripting Games finished last Friday. There’s always lots of PowerShell goodness to get you thinking! Richard has been detailing his solutions, and the complete list is available on the Scripting Guy blog.

Microsoft also held a Virtual Conference last week and the video’s are available here.

MDT 2010 Beta 2 has just been released and promises to hold a lot of great improvements. Michael, has shot out a whole bunch of posts in short time detailing some of the new features here.

Lots of great stuff to watch and play with! :-)

Weekly Poll #5

Adam Bell — Mon, 26 May 2008 10:12:37 +0000

This weeks poll is about 3rd party applications for PowerShell.

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

If you feel I’ve omitted someone please drop me a comment. For details check the PowerShell Toolbox

Weekly Poll #4

Adam Bell — Tue, 20 May 2008 09:45:43 +0000

So due to an unfortunate hardware situation we missed last weeks Poll, but It’s been resolved now, and so here’s Poll #4:

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

Here’s the detailed breakdown of the features in the 2.0 CTP

Weekly Poll #3

Adam Bell — Tue, 06 May 2008 12:43:19 +0000

A little late this week, but here it is.
Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

If you feel I’ve missed any significant options please leave a comment. There’s becoming quite a tower of power, but I tried to keep the list reasonably short.

PowerGUI PowerPack Tutorial

Adam Bell — Wed, 30 Apr 2008 04:07:49 +0000

I have just finished watching a really good tutorial on how to create PowerPacks in PowerGUI.

This gives you a great insight into what can be done with PowerGUI and has given me a few ideas of my own ;)

Well done Kirk, and thanks to Dmitry for pointing it out!

Weekly Poll #2

Adam Bell — Mon, 28 Apr 2008 13:32:46 +0000

This weeks Weekly Poll is now up.

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

If you’d like to suggest a poll please email me with Weekly Poll in the subject line.

VMware Infrastructure Toolkit (for Windows) 1.0 Beta

Adam Bell — Fri, 28 Mar 2008 01:37:46 +0000

I’m still in the process of getting sorted now that I’m back home in Western Australia, so you have probably seen this one already.

Just in case though ;)

VMware have their VI toolkit in beta, and I’ve been lead to believe that it has lots of PowerShell goodness. There are apparently 102 cmdlets included so a lot to take a look at and play with.

I’ve just found out that my main machine is due to arrive on Sunday, so as I am currently a man of leisure, I should have some “play” time available over the next week or two :)

The toolkit beta is available here and there’s also a blog available.

Moving and Renaming objects in Active Directory

Adam Bell — Tue, 04 Mar 2008 16:07:46 +0000

I went to move some AD objects with PowerShell recently, and realised that I didn’t have any examples to hand. Despite covering AD permission delegation and GPO operations, I’d somehow missed the fairly obvious task of moving and renaming objects!

So this seemed like a good time fix that …

We need to bind to some objects in AD, starting with the Users OU, and a fictional OU for our example, Service Accounts where we will move our objects to.



$root = [adsi]""

$users = [adsi]("LDAP://cn=users,"+$root.distinguishedName)

$sa = [adsi]("LDAP://ou=Service Accounts,"+$root.distinguishedName)

Now that we have bindings to the directory locations, we need to bind to an account we’d like to move.



$admin = [adsi]("LDAP://cn=Administrator,"+$users.distinguishedName)

The actually moving of an object isn’t made available through the PowerShell wrapper from what I could see. So to achieve this we need to expose the raw .Net methods using psbase.



$admin.psbase | get-member | where-object {$_.Name -eq "MoveTo"}

System.Void MoveTo(DirectoryEntry newParent), System.Void MoveTo(DirectoryEntry newParent, String newName)

I already knew the name of the method we’d need to use MoveTo(), so we used a where-object cmdlet to reduce our output to just what we needed. Looking at the above method, we can see that we can also rename the object by passing a second set of parameters.

Having bound to the Service Accounts OU, and the Administrator account, the only thing left to do is the actual move:



$admin.PSBase.MoveTo($sa)

Something to bear in mind if we want to rename an object, is that we could pass the same DirectoryEntry location as the object current exists in, or a new location. This method won’t update the sAMAccountName attribute.

If you want to change attributes on an object, it’s worth doing this before the move, and the binding becomes invalid. In our example of renaming the account, there’s a couple of attributes worth changing:



$admin.put("sAMAccountName", "zNobodyHere")

$admin.put("Description", "Nobody Service Account")

$admin.put("userPrincipalName", "zNobodyHere@leadfollowmove.com")

$admin.Setinfo()

Renaming, the Administrator account, and keeping it in the Users container:



$admin.PSBase.MoveTo($users, "cn=zNobodyHere")

Renaming the Administrator account, and moving it to our Service Accounts OU:



$admin.PSBase.MoveTo($sa, "cn=zNobodyHere")

Alternatively, you could use the Quest AD cmdlets to move or rename. Sometimes, however you don’t always have the tools available that you might like!

Windows 2003 DNS Server rights issue

Adam Bell — Wed, 27 Feb 2008 14:45:11 +0000

Apparently there is a permissions issue regarding hosting DNS zones in the ForestDNSZones, or DomainDNSZones partitions in Server 2003. I haven’t looked to see if this has been resolved in 2008. The issue and solution is detailed in Microsoft KB939090.

This issue occurs because of the permissions that are set in the Active Directory directory service….
The members of the DnsAdmins group do not have permissions on the following application partitions:
CN=MicrosoftDNS,DC=ForestDNSZones,DC=Domain…
CN=MicrosoftDNS,DC=DomainDNSZones,DC=Domain…

The documented solution is to edit your Active Directory with ADSIEdit and go in to fix the problem:

To resolve this issue, set permissions for the DnsAdmins group on the DomainDNSZones application partition and on the ForestDNSZones application partition.

We have taken a pretty close look at manipulating permissions in AD with PowerShell before, covering:
Standard Rights
Removing Rights in AD
Inheritance and Propagation
Extended Rights
and Controlling Access Rights in AD

We’re going to build a function similar to Add-DsAce.ps1 we used in the Standard Rights post, but this time we’re going to use a slightly different constructor, so that we can apply the correct inheritance. We want this to affect “This object and all Child Objects”, which means we need to use:



[System.DirectoryServices.ActiveDirectorySecurityInheritance]"SelfAndChildren"

So, our modified function looks like this:
Add-DsAce2.ps1



#----------------------------------------------------------------------------------------------------------

function Add-DsAce

#----------------------------------------------------------------------------------------------------------

{

Param (

  $DSobject,

  $Identifier,

  $DSrights,

  $AccessType = "Allow",

  $Inheritance

  )

  # GetAccessRules: Explicit ACE's, Inherited ACE's, TargetType

  $account = New-Object system.security.principal.ntaccount($Identifier)

 

  # Retrieve the SID - as a manual step you can check it's not empty :)

  $sid = $account.translate([system.security.principal.securityidentifier])

 

  $Inheritance = [System.DirectoryServices.ActiveDirectorySecurityInheritance]"SelfAndChildren"

  $ace = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($account, $DSrights, $AccessType, $Inheritance)

  $DSobject.psbase.get_objectsecurity().AddAccessRule($ace)

  $DSobject.psbase.CommitChanges()

}

#----------------------------------------------------------------------------------------------------------

Now that we have the ability to modify the AD, and presuming we dot source the newly created function we could do the following:



$root = [adsi]""

$ForestDNSZones = [adsi]("LDAP://DC=ForestDNSZones,"+$root.distinguishedName)

$DomainDNSZones = [adsi]("LDAP://CN=MicrosoftDNS, DC=DomainDNSZones,"+$root.distinguishedName)

 

Add-DSace $ForestDNSZones "DNSAdmins" "GenericAll"

Add-DSAce $DomainDNSZones "DNSAdmins" "GenericAll"

Basically, we’ve bound to AD via ADSI so that we can dynamically provide the domain DN, and the two locations in AD we want to apply the ACE to. Then it’s just a matter of passing the created function the parameters needed.