Monthly Archives: September 2012

SCVMM 2012 won’t install! HELP!

Ran into a simple one today to share.  Wish I grabbed the screen shot today.

I noted my new install of SCVMM 2012 wouldn’t finish on my copy of Server 2008R2 Enterprise.   It complained about being unable to launch Powershell and Failover clustering in the final window.

The answer? Duh! Make sure the Failover Clustering RSAT is installed on the SCVMM Server.  I just went ahead and cheated and threw them all on.

Import-Module ServerManager; GET-WindowsFeature *RSAT* | Add-WindowsFeature; RESTART-COMPUTER

I reran the Install and I have SCVMM2012 running happily now. Smile

FacebookTwitterGoogle+Share

Get Group Membership from NT4 with Windows Powershell for Migration to Windows Server 2012

Ok.  One last bit of madness.  

I would play with an Exchange 5.5 scenario but the funny thing is, I don’t think I have the Media anywhere…. Maybe if I ask Kevin nicely.

The whole point of this task wasn’t to really so much Manage an NT4 server but to determine what data I COULD pull from a legacy Domain that was so far out of support, you’d be stuck.  I wanted to see what Powershell could REALLY do.  I’ve been impressed.

My final task I decided was to try and pull out Group memberships from archaic and stale domain.   Completely migrate whatever we could onto a new platform.

Having the Groups created in Active Directory from the old NT4 domain just saves me typing.   It’s NICE but it’s not the whole beast.   Getting the user membership migrated over, THAT’S the big time saver.

So in our CONTOSO domain we obtained the groups by Binding to the Domain with the [ADSI] provider and then running a quick Cmdlet to filter out only Groups.

$NTDomain=[ADSI]”WinNT://CONTOSO”

$Groups=$NTDomain.psbase.children | where { $-.SchemaClassName –eq “group” }

But the bigger challenge would be to pull  out the memberships and store them into something useful (Like say a CSV file?  With the GroupName in a column?)

I found that if I ran a direct bind to a group like this

$groupname=[ADSI]”WinNT://CONTOSO/Administrators”

$groupname.members()

I could pull out Something.  But the something was a result like below

image

But thanks to a posting from Brandon Shell (@bsonposh) I found, “Enumerating Local Group Membership” this wasn’t so bad.  

Well, I fibbed.  It LOOKED bad because it involved a funky method that made my head hurt, but his solution worked perfectly.   You had to pipe each member of the returned array into THIS to get the Name of the User.

$-.gettype().invokemember("Name",’GetProperty’,$null,$-,$null)

Now I know why I hated working with NT4!

So running our initial list of Group Members through Brandon’s special Powershell decoder ring….

$Groupname.members() | foreach { $-.gettype().invokemember("Name",’GetProperty’,$null,$-,$null)}

and we now have USEFUL information.

image

Now to pull out this pile and produce something useful CSV output

We also have the list of Groups from Before.   Within the property returned is “PATH” which is the Path we need to bind to with [ADSI].   We’ll use that to individually bind to the Groups, pull their membership and output all to a CSV file we’ll build.

# Bind to the NT4 Domain Contoso

$NTDomain=[ADSI]”WinNT://CONTOSO”

$Groups=$NTDomain.psbase.children | where { $-.SchemaClassName –eq “group” }

# Define my Quotes and commas

# Honestly?  It’s to avoid my blog software switching the characters on me

# I could just as well use this ‘”Groupname”,”Groupmember”’

# But every so often the characters switch.

# Besides, this is more readable Smile

$quote=[char][byte]34

$comma=[char][byte]44

# Create a blank file to hold the data

NEW-ITEM C:\Powershell\Groupmembers.csv –itemtype file –force

# Add the Header to our CSV file

add-content –value ($Quote+”GroupName”+$quote+$comma+$Quote+”Groupmember”+$quote) –path c:\powershell\groupmembers.csv

# Step through the Groups

$groups | foreach {

# Store away the Group name

$name=$-.Name;

# Step through the membership

$-.members() | foreach {

# Run this through Brandon Shell’s (@bsonposh) secret Decoder ring…

$member=$-.gettype().invokemember("Name",’GetProperty’,$null,$-,$null)

# Store away the data and place it into a CSV file

$Data=$quote+$Name+$quote+$comma+$quote+$Member+$quote

add-content –value $data –path C:\Powershell\Groupmembers.csv

}

}

At the end you should have a CSV file that looks like this

image

Which if you copy over to a USB key (And presuming you already created the Group names in the Server 2012 BEFORE with the previous data gathering session) you could do something like this to populate the groups.

IMPORT-CSV C:\Powershell\GroupMembers.csv | Foreach { ADD-ADGROUPMEMBER $-.Groupname $-.Groupmember }

Oh look.  All my memberships populated in a NEW Domain Smile Sweeeeet.

Feelin’ that Power flowing free with PowerShell

Sean
The Energized Tech

FacebookTwitterGoogle+Share

Get Group Membership from NT4 with Windows Powershell for Migration to Windows Server 2012

Ok.  One last bit of madness.  

I would play with an Exchange 5.5 scenario but the funny thing is, I don’t think I have the Media anywhere…. Maybe if I ask Kevin nicely.

The whole point of this task wasn’t to really so much Manage an NT4 server but to determine what data I COULD pull from a legacy Domain that was so far out of support, you’d be stuck.  I wanted to see what Powershell could REALLY do.  I’ve been impressed.

My final task I decided was to try and pull out Group memberships from archaic and stale domain.   Completely migrate whatever we could onto a new platform.

Having the Groups created in Active Directory from the old NT4 domain just saves me typing.   It’s NICE but it’s not the whole beast.   Getting the user membership migrated over, THAT’S the big time saver.

So in our CONTOSO domain we obtained the groups by Binding to the Domain with the [ADSI] provider and then running a quick Cmdlet to filter out only Groups.

$NTDomain=[ADSI]”WinNT://CONTOSO”

$Groups=$NTDomain.psbase.children | where { $-.SchemaClassName –eq “group” }

But the bigger challenge would be to pull  out the memberships and store them into something useful (Like say a CSV file?  With the GroupName in a column?)

I found that if I ran a direct bind to a group like this

$groupname=[ADSI]”WinNT://CONTOSO/Administrators”

$groupname.members()

I could pull out Something.  But the something was a result like below

image

But thanks to a posting from Brandon Shell (@bsonposh) I found, “Enumerating Local Group Membership” this wasn’t so bad.  

Well, I fibbed.  It LOOKED bad because it involved a funky method that made my head hurt, but his solution worked perfectly.   You had to pipe each member of the returned array into THIS to get the Name of the User.

$-.gettype().invokemember("Name",’GetProperty’,$null,$-,$null)

Now I know why I hated working with NT4!

So running our initial list of Group Members through Brandon’s special Powershell decoder ring….

$Groupname.members() | foreach { $-.gettype().invokemember("Name",’GetProperty’,$null,$-,$null)}

and we now have USEFUL information.

image

Now to pull out this pile and produce something useful CSV output

We also have the list of Groups from Before.   Within the property returned is “PATH” which is the Path we need to bind to with [ADSI].   We’ll use that to individually bind to the Groups, pull their membership and output all to a CSV file we’ll build.

# Bind to the NT4 Domain Contoso

$NTDomain=[ADSI]”WinNT://CONTOSO”

$Groups=$NTDomain.psbase.children | where { $-.SchemaClassName –eq “group” }

# Define my Quotes and commas

# Honestly?  It’s to avoid my blog software switching the characters on me

# I could just as well use this ‘”Groupname”,”Groupmember”’

# But every so often the characters switch.

# Besides, this is more readable Smile

$quote=[char][byte]34

$comma=[char][byte]44

# Create a blank file to hold the data

NEW-ITEM C:\Powershell\Groupmembers.csv –itemtype file –force

# Add the Header to our CSV file

add-content –value ($Quote+”GroupName”+$quote+$comma+$Quote+”Groupmember”+$quote) –path c:\powershell\groupmembers.csv

# Step through the Groups

$groups | foreach {

# Store away the Group name

$name=$-.Name;

# Step through the membership

$-.members() | foreach {

# Run this through Brandon Shell’s (@bsonposh) secret Decoder ring…

$member=$-.gettype().invokemember("Name",’GetProperty’,$null,$-,$null)

# Store away the data and place it into a CSV file

$Data=$quote+$Name+$quote+$comma+$quote+$Member+$quote

add-content –value $data –path C:\Powershell\Groupmembers.csv

}

}

At the end you should have a CSV file that looks like this

image

Which if you copy over to a USB key (And presuming you already created the Group names in the Server 2012 BEFORE with the previous data gathering session) you could do something like this to populate the groups.

IMPORT-CSV C:\Powershell\GroupMembers.csv | Foreach { ADD-ADGROUPMEMBER $-.Groupname $-.Groupmember }

Oh look.  All my memberships populated in a NEW Domain Smile Sweeeeet.

Feelin’ that Power flowing free with PowerShell

Sean
The Energized Tech

FacebookTwitterGoogle+Share

Powershell–I went slightly mad and created a user in NT4

Now listen clearly.  This is NOT a hack.  It’s meant to do this. 

I can also hear a few people (ok, MORE than a few, a LOT) screaming “WHY?! WHY?!? WHYYYY????!??!!!!”

Just cuz.  I was curious if it could work and to what degree.

So here we have a lovely little Domain on an NT4 server called “CONTOSO”, leftover from my previous session of pulling users out. 

I wanted to see just what it would take.

Process is simple actually.

Bind to the Domain

Create a user object

Populate the necessary fields

Set it in stone

Now if there are any small children watching this?  BACK AWAY!  I am working with a VERY old and INSECURE system that might just Blue Screen and eat something.

Bind to the Domain while logged as an account with Domain Admin rights

$NTdomain=[ADSI]”WinNT://CONTOSO”

Create the User Object

$NEWUser=$NTDomain.psbase.Children.add(“John Smith”,”user”)

Populate the necessary fields

$NEWUser.setPassword(“ReallyStupidPasswordSinceThisIsNT4”)

$NewUser.Put(“Description”,”Our Standard Generic User”)

Set it in stone

$Newuser.Setinfo()

Yes.  It works.  It follows the exact same principals and rules when creating and modifying local machine accounts and groups in Windows 7.

I’m not quite sure where this is actually USEFUL but it was fun messing about Smile

The Power of Shell took me over!

Sean
The Energized Tech

FacebookTwitterGoogle+Share

Powershell–I went slightly mad and created a user in NT4

Now listen clearly.  This is NOT a hack.  It’s meant to do this. 

I can also hear a few people (ok, MORE than a few, a LOT) screaming “WHY?! WHY?!? WHYYYY????!??!!!!”

Just cuz.  I was curious if it could work and to what degree.

So here we have a lovely little Domain on an NT4 server called “CONTOSO”, leftover from my previous session of pulling users out. 

I wanted to see just what it would take.

Process is simple actually.

Bind to the Domain

Create a user object

Populate the necessary fields

Set it in stone

Now if there are any small children watching this?  BACK AWAY!  I am working with a VERY old and INSECURE system that might just Blue Screen and eat something.

Bind to the Domain while logged as an account with Domain Admin rights

$NTdomain=[ADSI]”WinNT://CONTOSO”

Create the User Object

$NEWUser=$NTDomain.psbase.Children.add(“John Smith”,”user”)

Populate the necessary fields

$NEWUser.setPassword(“ReallyStupidPasswordSinceThisIsNT4”)

$NewUser.Put(“Description”,”Our Standard Generic User”)

Set it in stone

$Newuser.Setinfo()

Yes.  It works.  It follows the exact same principals and rules when creating and modifying local machine accounts and groups in Windows 7.

I’m not quite sure where this is actually USEFUL but it was fun messing about Smile

The Power of Shell took me over!

Sean
The Energized Tech

FacebookTwitterGoogle+Share

Powershell–Get my users from NT 4.0 to Windows Server 2012

Now before I go anywhere with this I have to take off my Tilley and bow to my co-worker Kevin McKeown.   I looked over at him the other day and said “Hey, any chance you have NT4 server anywhere in the archives?”

Kevin ran off into his private dungeon somewhere in Northern Canada, dug through piles of Commodore cables, various bits and pieces of SCSI1 drives and a small toad (don’t ask) and bounced into the office Monday.

“You mean these?” He laid out before be not ONLY the original NT4 Server media, the Option Pack but EVEN NT4 workstation.”

“I’m pretty certain these disks won’t work.  They’ve been buried in the basement for YEARS.”

I shrugged and started down the path to my Doom on my Windows 7 workstation, only armed with Windows Virtual PC, a pre-installed Windows XP Mode, some ancient media and a cross of the fingers.

The first part was installing NT4 into Windows Virtual PC.  Very interesting that it DID pick up the Native Network card and Windows Virtual PC provided a Video card NT4 liked.   I actually had COLORS and NETWORKING.

Spinning up the old Wizard, I choose to enable it as a Primary Domain Controller for the CONTOSO domain with a Static IP Address of 192.168.45.10

Then it was time to get workstation on this puppy that could use Powershell.  I initially tried Windows 7, it looked up at me and said “NT4, are you KIDDING?!” so I dropped to a machine I knew WOULD work with NT4 in the past, Windows XP, which could also use a currently supported version of Powershell.

We start off with an ordinary Windows XP workstation.  Nothing up this sleeve, nothing up here (tapping head) and

Join Windows XP to NT 4 Domain

We follow the following two articles first BEFORE joining Windows XP to the NT4 domain

Ensure NetBIOS over TCP/IP is Enabled under the WINS tab in TCP/IP and pointing to the NT 4.0 WINS Server

As per Knowledge Base: 318266 – A Windows XP Client Cannot Log On to a Windows NT 4.0 Domain Disable the option in the Windows XP workstation for “Domain Member:Digitally encrypt or sign secure channel data (always)” to Disabled

…and then join a computer to the Domain in whatever manner you deem normal (Yes, even if that means you’re juggling Eggs and singing the latest pop hits while wearing a beanie)

image

Now that you’ve dropped your Security pants, you can manage this sucker

Install .NET Framework 2.0 SP1 and Windows Management Framework 2.0 (Powershell 2.0) on that computer to make this all happen.  Without this, I wouldn’t be able to use the word “Powershell” in the title of the article.

Now the first trick is to Bind to the CONTOS Domain with Windows Powershell.  We’re going to be using the older WinNT provider here (Yes, Powershell was designed to talk to an NT4 Domain, how cool is that?)

$NTDomain=[ADSI]”WinNT://CONTOS”

Once you have bound yourself to the Albatross (er… security hol…. NT4 Domain!) you can at least start doing some queries.  

PHASE 1 – COLLECT UNDERPANTS!

No, wait.  Obtain DATA from old Domain CONTOSO

Get your list of User accounts

$userlist=$NTDomain.psbase.children |  Where { $-.SchemaClassName –eq “user” } | Select-object Description,Name,Fullname,HomeDirDrive,HomeDirectory,LoginScript,objectSID,PrimaryGroupID,UserFlags

image

Get a list of your Domain Groups

$grouplist=$NTDomain.psbase.children |  Where { $-.SchemaClassName –eq “group” } | Select-object Description,Name,GroupType,objectSID

And perhaps your computers?

$computerlist=$NTDomain.psbase.children |  Where { $-.SchemaClassName –eq “computer” } | Select-object Division,Name,OperatingSystem,OperatingSystemVersion,Owner,Processor,ProcessorCount

Now suddenly with this information in our hands, doesn’t it all seem possible?  We can store away the data as CSV files for our new Server 2012 domain in the following manner.

$userlist | export-csv c:\powershell\userlist.csv

$grouplist | export-csv c:\powershell\grouplist.csv

$computerlist | export-csv c:\powershell\computerlist.csv

Now that the data you want is in something clean like a CSV file, you can bring that over to your DC on the new Windows Server 2012 domain, or nearest handy workstation enabled with RSAT and the Active Directory Module.

PHASE 2 – ??? –

Oh right, Import Accounts, Computers and Groups into NEW Domain Fabrikam.local

Once you are on the new machine you can use the following script to rebuild the Groups in Active Directory

$grouplist Import-CSV C:\Powershell\Grouplist.csv

[array]$groups="Global"
[array]$groups+="DomainLocal"

$grouplist | foreach { new-adgroup –GroupScope ($groups[(([int]$-.GroupType)/2)-1] ) –DisplayName $-.Name –Name $-.Name –Description $-.Description }

Smiling now?  A LITTLE BIT LESS TYPING?

It gets better.   Now we can pre-populate all of your computers in Active Directory.

$computerlist Import-CSV C:\Powershell\Computerlist.csv

$computerlist | foreach { new-adcomputer –Name $-.Name –DisplayName $-.Name –description $-.Division }

Now importing staff is a little different.  We’re playing a very basic scenario in which we don’t have Exchange 5.5 (although if you are creative, Powershell I believe can query IT via LDAP) but we’ll have a simple scenario with the following details.  One of things we WILL have to do since Windows NT has a VERY basic UserID setup is Split the FullName into some userful details before creating it.

$userlist=import-csv C:\poweshell\userlist.csv

$UPN=’@fabrikam.local’
$Path=’OU=Users,OU=Offices,DC=Fabrikam,DC=local’
$DOMAIN=’FABRIKAM’

$userlist | foreach {

$Password=(CONVERTTO-SecureString ‘BadPassword1’ –asplaintext –force)

$LoginID=$-.Name+$UPN

$GivenName=($-.Displayname.split(“ “))[0]

$Surname=($-.Displayname.split(“ “))[1]

NEW-ADUSER –path $Path -name $-.Displayname -displayname $-.DisplayName -description $-.Description –accountpassword $Password -changepasswordatlogon $TRUE -enabled $TRUE -givenname $Givenname -homedirectory $-.HomeDirectory -homedrive $-.HomeDirDrive -userprincipalname $LoginID -samaccountname $-.Name -sc
riptpath $LoginScript -surname $Surname

}

PHASE 3 – PROFIT! (Yes sit back and let the computer do the work!)

The Scripts make take some time to populate your Active Directory depending on the size of your old Domain but imagine how you could just sit back and bill for what every else says “Whoa! dude! Migrate NT4 to Windows Server 2012? Not gonna happen”

Well we might not get a direct migration, but we can sure get our data out of the old Domain

Stick around, I’m going to try and create a user in this beast and see if I can pull some Group Memberships.

Remember, it’s all thanks to the POWER of Powershell!

Sean
The Energized Tech

FacebookTwitterGoogle+Share

Powershell–Get my users from NT 4.0 to Windows Server 2012

Now before I go anywhere with this I have to take off my Tilley and bow to my co-worker Kevin McKeown.   I looked over at him the other day and said “Hey, any chance you have NT4 server anywhere in the archives?”

Kevin ran off into his private dungeon somewhere in Northern Canada, dug through piles of Commodore cables, various bits and pieces of SCSI1 drives and a small toad (don’t ask) and bounced into the office Monday.

“You mean these?” He laid out before be not ONLY the original NT4 Server media, the Option Pack but EVEN NT4 workstation.”

“I’m pretty certain these disks won’t work.  They’ve been buried in the basement for YEARS.”

I shrugged and started down the path to my Doom on my Windows 7 workstation, only armed with Windows Virtual PC, a pre-installed Windows XP Mode, some ancient media and a cross of the fingers.

The first part was installing NT4 into Windows Virtual PC.  Very interesting that it DID pick up the Native Network card and Windows Virtual PC provided a Video card NT4 liked.   I actually had COLORS and NETWORKING.

Spinning up the old Wizard, I choose to enable it as a Primary Domain Controller for the CONTOSO domain with a Static IP Address of 192.168.45.10

Then it was time to get workstation on this puppy that could use Powershell.  I initially tried Windows 7, it looked up at me and said “NT4, are you KIDDING?!” so I dropped to a machine I knew WOULD work with NT4 in the past, Windows XP, which could also use a currently supported version of Powershell.

We start off with an ordinary Windows XP workstation.  Nothing up this sleeve, nothing up here (tapping head) and

Join Windows XP to NT 4 Domain

We follow the following two articles first BEFORE joining Windows XP to the NT4 domain

Ensure NetBIOS over TCP/IP is Enabled under the WINS tab in TCP/IP and pointing to the NT 4.0 WINS Server

As per Knowledge Base: 318266 – A Windows XP Client Cannot Log On to a Windows NT 4.0 Domain Disable the option in the Windows XP workstation for “Domain Member:Digitally encrypt or sign secure channel data (always)” to Disabled

…and then join a computer to the Domain in whatever manner you deem normal (Yes, even if that means you’re juggling Eggs and singing the latest pop hits while wearing a beanie)

image

Now that you’ve dropped your Security pants, you can manage this sucker

Install .NET Framework 2.0 SP1 and Windows Management Framework 2.0 (Powershell 2.0) on that computer to make this all happen.  Without this, I wouldn’t be able to use the word “Powershell” in the title of the article.

Now the first trick is to Bind to the CONTOS Domain with Windows Powershell.  We’re going to be using the older WinNT provider here (Yes, Powershell was designed to talk to an NT4 Domain, how cool is that?)

$NTDomain=[ADSI]”WinNT://CONTOS”

Once you have bound yourself to the Albatross (er… security hol…. NT4 Domain!) you can at least start doing some queries.  

PHASE 1 – COLLECT UNDERPANTS!

No, wait.  Obtain DATA from old Domain CONTOSO

Get your list of User accounts

$userlist=$NTDomain.psbase.children |  Where { $-.SchemaClassName –eq “user” } | Select-object Description,Name,Fullname,HomeDirDrive,HomeDirectory,LoginScript,objectSID,PrimaryGroupID,UserFlags

image

Get a list of your Domain Groups

$grouplist=$NTDomain.psbase.children |  Where { $-.SchemaClassName –eq “group” } | Select-object Description,Name,GroupType,objectSID

And perhaps your computers?

$computerlist=$NTDomain.psbase.children |  Where { $-.SchemaClassName –eq “computer” } | Select-object Division,Name,OperatingSystem,OperatingSystemVersion,Owner,Processor,ProcessorCount

Now suddenly with this information in our hands, doesn’t it all seem possible?  We can store away the data as CSV files for our new Server 2012 domain in the following manner.

$userlist | export-csv c:\powershell\userlist.csv

$grouplist | export-csv c:\powershell\grouplist.csv

$computerlist | export-csv c:\powershell\computerlist.csv

Now that the data you want is in something clean like a CSV file, you can bring that over to your DC on the new Windows Server 2012 domain, or nearest handy workstation enabled with RSAT and the Active Directory Module.

PHASE 2 – ??? –

Oh right, Import Accounts, Computers and Groups into NEW Domain Fabrikam.local

Once you are on the new machine you can use the following script to rebuild the Groups in Active Directory

$grouplist Import-CSV C:\Powershell\Grouplist.csv

[array]$groups="Global"
[array]$groups+="DomainLocal"

$grouplist | foreach { new-adgroup –GroupScope ($groups[(([int]$-.GroupType)/2)-1] ) –DisplayName $-.Name –Name $-.Name –Description $-.Description }

Smiling now?  A LITTLE BIT LESS TYPING?

It gets better.   Now we can pre-populate all of your computers in Active Directory.

$computerlist Import-CSV C:\Powershell\Computerlist.csv

$computerlist | foreach { new-adcomputer –Name $-.Name –DisplayName $-.Name –description $-.Division }

Now importing staff is a little different.  We’re playing a very basic scenario in which we don’t have Exchange 5.5 (although if you are creative, Powershell I believe can query IT via LDAP) but we’ll have a simple scenario with the following details.  One of things we WILL have to do since Windows NT has a VERY basic UserID setup is Split the FullName into some userful details before creating it.

$userlist=import-csv C:\poweshell\userlist.csv

$UPN=’@fabrikam.local’
$Path=’OU=Users,OU=Offices,DC=Fabrikam,DC=local’
$DOMAIN=’FABRIKAM’

$userlist | foreach {

$Password=(CONVERTTO-SecureString ‘BadPassword1’ –asplaintext –force)

$LoginID=$-.Name+$UPN

$GivenName=($-.Displayname.split(“ “))[0]

$Surname=($-.Displayname.split(“ “))[1]

NEW-ADUSER –path $Path -name $-.Displayname -displayname $-.DisplayName -description $-.Description –accountpassword $Password -changepasswordatlogon $TRUE -enabled $TRUE -givenname $Givenname -homedirectory $-.HomeDirectory -homedrive $-.HomeDirDrive -userprincipalname $LoginID -samaccountname $-.Name -sc
riptpath $LoginScript -surname $Surname

}

PHASE 3 – PROFIT! (Yes sit back and let the computer do the work!)

The Scripts make take some time to populate your Active Directory depending on the size of your old Domain but imagine how you could just sit back and bill for what every else says “Whoa! dude! Migrate NT4 to Windows Server 2012? Not gonna happen”

Well we might not get a direct migration, but we can sure get our data out of the old Domain

Stick around, I’m going to try and create a user in this beast and see if I can pull some Group Memberships.

Remember, it’s all thanks to the POWER of Powershell!

Sean
The Energized Tech

FacebookTwitterGoogle+Share