XP EOS D-9… And Counting…

2017-07-27T00:01:02+00:00 March 30th, 2014|Uncategorized|

It’s Monday.  The last day of March.  Forget the fact that tomorrow is April Fool’s Day.  The Windows XP “End of Service” date is now only 9 days away! 

Before reading on, it might be a good idea to reference my post from last month, “XP Elimination — The looming crush…” and “XP EOS M-9… And Counting…

Now that you’ve caught up on those previous articles, let’s spend a moment catching up on our 3 semi-fictitious companies and see how they are doing.

Organization “A” – What, me worry?

For our fictitious Organization “A”, things are actually getting better – at a price, that is.  You see, they realized they had no hope of making the deadline, and decided to throw buckets of money at the problem.  They brought in consultants, vendors, and staff leaders, and locked them in a room with a blank checkbook.  The 20,000 XP machines are rapidly becoming 7000 or so machines and dropping.  It’s “getting done”, but in a very “machine gun” style that doesn’t lend itself well to on-going management or future enhancements and upgrades.  This just means that after this checkbook is empty, they’ll be setting up for Round 2, in preparation for the next generation.  If they had gotten underway earlier, they could have had at least *some* of the tools and infrastructure in place to carry forward…  But, no…

Organization “B” – Nope.  We don’t wanna.

Well, Organization “B” is now partially integrated into Organization “C”.  They’re not going to make the deadline, I’m afraid; but because Organization “C” is so ruthlessly efficient, they are at least documenting the environment, planning the on-going integration, and actually deploying some elements of the extended infrastructure.  They still have most of the 40,000 XP workstations to get to, but the future looks better.  They’ve got fingers crossed that no calamity will befall them over the next few months as they catch up, and they are considering an alternate (expensive) support strategy.  It’s about the best they can do, given their previous situation.

Organization “C” – The best-laid plans…

For the original Organization “C” side of the C/B acquisition, things actually look pretty good.  Across the infrastructure, there are still a few thousand XP machines – but most of these are documented and/or isolated, or about to be replaced shortly.  It’s down to the wire!  But we can finally say that they’ve booked their project completion dinner party reservations.  Congratulations!  But keep at it with Organization B… 

Organization “D” – Yeah?  So?

Since my last post, I met Organization “D”.   Nice folks; smart too.  But they simply cannot afford to care about the deadline.   After a string of financial hardships, org changes, and so forth, they are only now making enough headway to think they’ll survive.  As a result of the hard past, they are only now putting their heads up for air and exploring option of how to get them from “here” to “there”.  They are numb from the scars of the economy, and they don’t see this XP EOS challenge any differently than the past challenges; they will run headlong into it, and take the blows.  They will come out the other end, but only with more scars.

Honestly, some of these stories are heartbreaking, while others are inspiring.  And mind you, I worked through the 2000 bubble like many of you, so you’d think I’d be less moved by the trials that these folks are going though.  But this one is different.  It didn’t make the news the same way (at least in the build-up), but it hits real folks where it hurts.  And we at Coretek are doing our absolute best to help those that we can, as quickly and effeciently — and as prudently — as we can. 

So good luck, hang in there, and we’ll all be watching the clock tick down to the final day.  And we’ll see you on the other side of the XP EOS…

[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]

Powershell with embedded VBS…

2017-07-27T00:01:03+00:00 November 21st, 2013|Uncategorized|

I recently have been working on a project where the client uses an application that requires a generic username and password to be passed to the database.  To further complicate the matter the users could not know or input the username/password…

To accommodate the project I started working with the logic and how to accomplish this goal.  I started Imprivata (A Single Sign on Application) and AppSense to launch the app at the end of the userinit process.  Unfortunately, this failed to function due to the outdated server version at the client site.  So I ended up with PowerShell to launch the application…

I wrote 26 lines of code (see below) to check if the script had been run before; if it hadn’t, then it would create a flag.  Once it completed, it would check the flag, run the script, expect Imprivata to proxy the credentials, and the day was saved, right?!? 

 

# Create Windows Shell Object to allow for window to be minimized
$shell = New-Object -ComObject "Shell.Application"
# Create Registry Key Flag if it doesn’t already exist
if (!(test-path -path HKCU:SoftwareCUSTOMER -pathType container))
{
  New-Item -Path HKCU:Software -Name CUSTOMER
  New-ItemProperty "HKCU:SoftwareCUSTOMER" -Name "SynapseLaunched" -Value 0 -PropertyType "DWord"
}
#Check the value of Synapse Launched
if ((Get-ItemProperty 'hkCU:softwareCUSTOMER' -name SynapseLaunched | select -exp SynapseLaunched) -ne 1) 
{ 
  #launch Synapse then minimize all windows
  & 'C:Windowsexplorer.exe' "::{1FBD11EF-1260-11D1-87A7-444553540001}"
  start-sleep -s 2
  $shell.minimizeall() 
  #countdown from 2 seconds to allow app to connect to server
  Start-Sleep -s 2
  #kill Explorer.exe and relaunch
  $proc = Get-Process
  foreach ($objItm in $proc) 
  {
    If ($objItm.ProcessName -eq "explorer") 
    {
       kill $objItm.ID
    }
  }
  #Set SynapseLaunched Dword Value to 1
  Set-ItemProperty 'hkcu:softwareCUSTOMER' -name SynapseLaunched -Value 1  
}  

…Sadly, not so.  Imprivata at the client site was outdated and would not be available to be used for Windows 7 at the site for 2 months, causing an unacceptable delay in the project. 

Well, after the Imprivata approach failed for me, I needed to accomplish what I couldn’t do in Imprivata.  I started by thinking that perhaps I could launch an explorer process (this app is an explorer shell extension) as run as user with my username…  But no dice; the launching of explorer like that didn’t work because it would cause the files I needed to be created in a non-existent user profile, and would error out on the server.

So, I fell back to Windows VBS scripting’s SendKeys.  Since my script was already in PowerShell, and scripting in autoIT or VBS is something I rarely do, I experimented with creating a new Shell object.  Below is the code that I used for that:

 

#proxy Credentials
      $wshell = new-object -com wscript.shell
      $wshell.AppActivate("Windows Security")
      $wshell.sendkeys("{ENTER}")
      start-sleep -m 30
      $wshell.AppActivate("OneSign")
      $wshell.sendkeys("{ENTER}")
      start-sleep -m 30
      $wshell.AppActivate("Windows Security")
      $wshell.sendkeys("USERNAME")
      $wshell.sendkeys("{TAB}")
      $wshell.sendkeys("PASSWORD_OF_USER")
      start-sleep -m 30
      $wshell.sendkeys("{ENTER}") 

By utilizing $wshell = new-object -com wscript.shell, I was able to tap into .Net commands to interact with windows.  Now I could utilize some old VB Scripting code I had laying around from the past…

By utilizing $shell = New-Object -ComObject "Shell.Application", I was able to manipulate the Explorer.exe shell and minimize/maximize windows as I saw fit…

This was a very rewarding exercise.  Through this solution we (Coretek) were able to solve the client’s issues with the app, accommodate both teams (Desktop and PACs), simplify the end user experience, and best of all bring Windows 7 deployments back on schedule!

Look out – Here comes IE 11!

2017-07-27T00:01:03+00:00 October 17th, 2013|Uncategorized|

For many of us that have been watching the recent pre-releases from Microsoft (Windows 8.1 tomorrow!), IE11 will be a welcome update.  In fact, it will be released as an “Important” update for Windows 7 and up, in order to ensure a large footprint.

However, some companies are barely getting through Windows 7 migrations, or have limited resources available to test their applications against the latest browser, and would like to slow the flow of the river of updates a bit…

So for people/companies that perform automatic updates (or standard deployment of “Important” updates) but *don’t* want IE11 to come down to their workstation, there is a toolkit available to stop the IE11 deployment for Windows 7 or Windows Server 2008 R2 when using Automatic Updates.  

http://www.microsoft.com/en-us/download/details.aspx?id=40722

Note that for those of you who have used these toolkits in the past for previous versions, the previous toolkits will not stop automatic deployment of IE11, since each uses a different set of registry keys.

Now get that migration done, so you can go to Windows 8.1!!

XP EOS M-9… And Counting…

2017-07-27T00:01:03+00:00 July 17th, 2013|Uncategorized|

The Windows XP “End of Service” date is now only 9 months away!  Well, we’re actually just beyond 9-month mark now, but you get the point.

Before reading on, it might be a good idea to reference my post from last month, “XP Elimination — The looming crush…

If you think it’s ridiculous or hilarious that anyone should be concerned about migrating off of XP at this point, then you probably work in a small-to-medium sized company.  You might even be able to consider upgrading all the workstations by yourself (or with a buddy), or maybe you’ve just replaced all the computers with modern devices with updated OS’s.  Easy-peasy.

But many *large* enterprise company/organizations are watching the clock (or should be) for that looming April 8th deadline, for a variety of reasons.  And this is what I really wanted to touch on today — the fact that steering the massive enterprise can be like steering the largest ship in an ocean, but there are other factors to consider in the metaphorical ocean as well.  Like icebergs…  Like other, older ships that require rescuing… 

Okay, I’ve worn out the metaphor, so let’s start discussing some specifics.  Let’s look at the examples of three, ahem, *fictitious* example large organizations that have arrived at three different XP situations.

Organization “A” – What, me worry?

For our fictitious Organization “A”, things are smooth sailing.  Or so they think.  They’ve got only 20,000 XP machines, and they’ve set up a test pilot bed of about 50 Windows 7 machines, and it’s going well.  Well, *that* part’s going well.  What they will soon realize is that their back-end infrastructure isn’t prepared (in design nor scale) for the type of load that their Win7 deployment strategy calls for — and they have only just begun to prepare their applications for re-packaging.  But they aren’t worried.  Well, not as much as they should be, anyway.

Organization “B” –  Nope.  We don’t wanna.

Organization “B” doesn’t have a plan.  It’s not that they don’t have a clue, it’s just that they mostly don’t care.  They have 40,000 workstations, a bunch of old servers, and so on, in a complicated, aging infrastructure.  You see, things don’t really look good for the business end of the company in this age of consolidation, and most folks think they’ll be acquired anyway.  So XP is fine for now.  I guess.  Whatever.

Organization “C” – The best-laid plans…

For Organization “C”, they really have been doing it right.  They jumped in front of the project, and designed/prepared/deployed a sturdy, modern back-end infrastructure.  They rallied the troops and started the application re-packaging very early-on and devised a “just-in-time” strategy to manage application-to-user/workstation tracking and roll out the workstations right behind the infrastructure and apps.  The working schedule seems to indicate that all of their 50,000 workstations should be upgraded/re-deployed right around the the April 8th deadline.  Whew!  It looks like they’re going to make it!  Until…  Uh-oh…  Did we mention that Organization “C” just acquired Organization “B”? 

While these are hypothetical scenarios, I will be re-visiting these imaginary companies over the next few months as we approach the XP EOS date, discussing some of the finer points of their challenges along the way…  Let’s wish them all luck, shall we? 

😉

 

 

 

A cool ‘Remote Desktop Connection Manager’ tip!

2017-07-27T00:01:04+00:00 April 3rd, 2013|Uncategorized|

I am constantly monitoring multiple Microsoft Windows Servers and XP workstations via Remote Desktop Connection Manager and having to switch between each console one at a time is a very user-intensive and time-consuming process.  Though, I have recently discovered a very useful and time-saving trick that I will share with you below…

First, by default, the Remote Desktop Connection Manager gives you a thumbnail view of all of your workstations when you click on any “group” of servers from the left server pane list.  I always thought this was a “gimmick” and never thought twice about using it for anything because the dimensions of the thumbnail views of the remote desktops were just way too small to be useful.

But after reviewing the program’s options I found that you can modify the size of the thumbnails (Tools > Options > Client Area > Thumbnail Size)!

But that isn’t all!

The thumbnails are actual “live” clickable Remote Desktop sessions; so if you set the pixel size of the thumbnails to 25%, 30% or 40% of your screen size, you can fit 4-12 active server connections into one very productive window (obviously depending on your monitor size and screen resolution!).  This screen cap should give you a good idea of what I mean:

screenshot

 

I hope you find this tip as useful as I did!  Enjoy!

 

 

Scripted Home Folder Management with PowerShell Pt. 6 – The Script!

2017-07-27T00:01:07+00:00 October 3rd, 2012|Uncategorized|

This is the last post in my series on scripting user and Home Folder management (see Part 1, Part 2, Part 3, and Part 4 and Part 5 for reference) — it was a lot of ground to cover, but we did it!  Thanks for hanging in there with me.  We’ve created the user and attributes, built the folder, set permissions, added the Home Folder attribute on the user object; all with PowerShell.  You don’t get much more real-world than that!

Now, as promised, it’s time to pull it all together into one example script.

Of course, now that we’re putting all the concepts from the previous posts together, we need to be smart and add a few smart/standard script things; like good use of variables, error checking, and so forth.  Specifically, the new things I’m introducing in this post are:

  • Use of variables  – To make the script portable and easily modifiable
  • Use of command line arguments – To accept the new user’s name as input arguments
  • Use of SubString – To generate a “UserName” (a.k.a. SamAccountName) from a first and last name
  • Check for pre-existing – To make sure we don’t attempt to create an already-existing user name

All of the items above are in the first section of the script below, and the remaining sections are where I pull in the concepts from the previous posts to get it all done.  I don’t want to go into great detail on these new items, but they are necessary to make the script flow correctly and be usable right away as-is.

So, here you go.  You can paste this right into a file (something like provisionNewUser.ps1), launch a PowerShell session, and run it with the new user’s First Name and Last Name on the command line (as explained early in the body of the script). 

And here’s my warning: Don’t ever do what people on the Internet tell you to do; if this script is scary to you, don’t run it.  In fact, only run this in a test lab, until you are comfortable with the specifics.  So there.

# Home Folder Provisioning Demo Script
# Jeremy Pavlov, Coretek Services, 20121003
#
# Execute in a powershell session, with the new user's First and Last names after the command, like this:
# .provisionNewUser.ps1 Jeremy Pavlov
# # Make sure you run this if not already loaded, for AD-based commands Import-Module ActiveDirectory # # Read in the first name and last name from command line inputs $FirstName = $args
[0] $FirstInitial = $FirstName.Substring(0,1) $LastName = $args[1] $LastInitial = $LastName.Substring(0,1) $UserName = "$FirstInitial$LastName" $MyDomain = "CoretekServices.local" $HomePrefix = "\$MyDomainCorpHomes" $DefaultUserOu = "ou=New Users,dc=CoretekServices,dc=local" # write "First name will be: $FirstName" write "Last name will be: $LastName" write "User name will be: $UserName" write "Home Folder will be: $HomePrefix$LastInitial$UserName" write "" # # See if the user exists $CheckUser = Get-ADUser -ldapFilter "(SamAccountName=$UserName)" # #If user exists, exit! if ($CheckUser -ne $Null) { write "User $UserName already exists! Exiting..." write "" exit } # write "Creating $UserName..." write "" New-ADUser -Path "$DefaultUserOu" -SamAccountName "$UserName" -Enabled $true -Name "$FirstName $LastName" -GivenName "$FirstName" -Surname "$LastName" -AccountPassword (ConvertTo-SecureString –AsPlaintext "ChangeMe123!" –Force) -ChangePasswordAtLogon $true # write "Create $HomePrefix$LastInitial$UserName ..." write "" New-Item -type directory -path $HomePrefix$LastInitial$UserName # write "Setting permissions on the $HomePrefix$LastInitial$UserName ..." write "" $acl = Get-Acl $HomePrefix$LastInitial$UserName $rule = New-Object System.Security.AccessControl.FileSystemAccessRule("$MyDomain$UserName", "DeleteSubdirectoriesAndFiles, Modify, Synchronize", "ContainerInherit, ObjectInherit", "None", "Allow") $acl.AddAccessRule($rule) Set-Acl $HomePrefix$LastInitial$UserName $acl # write "Setting the Home Folder attribute for $UserName" write "" Set-ADUser -identity "$UserName" -homeDrive h: -homeDir "$HomePrefix$LastInitial$UserName" # write "...Complete!" write "" #

…and there you have it.  Now, of course, I could have dumped in a lot of other good practice stuff like input validations and things, or other additional neat features, but I’m only trying to demonstrate the core concepts here from our previous posts in this series.  I don’t want to over-whelm the example and make it difficult or — heaven forbid — boring (gasp!) to read.

But please, if you have a better way of doing it, make sure to drop a comment or two and help out others…

Now go create some users!

 

 

Scripted Home Folder Management with PowerShell Pt. 5

2017-07-27T00:01:07+00:00 September 26th, 2012|Uncategorized|

In my last post in this series on scripting user management (see Part 1, Part 2, Part 3, and Part 4 for reference), I left off with a couple different ways to set the Home Folder attribute, using DSMod or PowerShell.

But I thought it was important to spend a moment and stress that when you’re scripting these changes, it’s all about what you *have* available to use as the basis of your queries and changes.  What I mean is this:  If you only have the samAccountName (often called the User ID), you make the query/change one way; but if you have the CN (known as the User Name), then you do it another way.  Let me show you some examples…

DSMod

As shown in Part 4, if you have the CN — as DSMod requires — you can just make the call directly:

dsmod user "cn=Jeremy Pavlov,ou=Demo,dc=CoretekServices,dc=local" -hmdrv H: -hmdir "\MyCompany.orgDFSPathHomes$username$"

But what if you don’t know the CN, and all you have is the samAccountName?  Then in this case, you must use the samAccountName to first *get* the CN, then pipe the CN through to the DSMod command like this:

dsquery user -samid "JPavlov" | dsmod user -hmdrv H: -hmdir "\MyCompany.orgDFSPathHomes$username$"

In the above example, we’re using dsquery to simply retrieve the samAccountName, as represented by the samid flag; which returns a perfectly-formatted CN that is used as input for the DSMod.  The bottom line is that you can make the change no matter which format you have the User name!

PowerShell

On the PowerShell side of things, you have a similar flexibility.  The PowerShell example I used in Part 4 utilized the samAccountName (as represented by the -identity flag) instead of the CN, like this:

Set-ADUser -identity "jpavlov" -homeDrive h: -homeDir "\MyCompany.orgDFSPathHomesjpavlov"

But if you only have the CN to start with, then we have to go fishing.  We need to do a Get-ADUser with the -like option, and stuff it in a variable, prune that variable down to just what we want, and then pass it on to the Set-ADUser command.  Here’s one example how to get it done, like this:

$Dude = Get-ADUser -Filter 'Name -like "Jeremy Pavlov"'
$DudeSamId = $Dude.SamAccountName
Set-ADUser -identity $DudeSamId -homeDrive h: -homeDir "\MyCompany.orgDFSPathHomes$DudeSamId"

And with that, we’ll press pause, until next time…

Next time…  Let’s wrap this scripting up…  See you then!

Scripted Home Folder Management with PowerShell Pt. 4

2017-07-27T00:01:07+00:00 September 19th, 2012|Uncategorized|

If you’ve been following along in this post series (see Part 1, Part 2, and Part 3 of this series for reference), where I showed you how to create AD users, create soon-to-be Home Folders, and set permissions; all with PowerShell (and some other tools). 

Now, it’s time to stitch it all together by assigning the Home Folder attribute on our user object, and point the attribute to the folder we’ve prepared.  Yes, of course you could just set the Home folder “Connect To” options on the Profile tab of a User object in the Active Directory Users and Computers (ADUC) tool, but that’s not the point.  We want scripting!

So to pick up where we left off last time, all we really need to do is provide a Home folder attribute update on an existing user object.  Of course, we could have done this upon initial creation, but this series of posts is attempting to demonstrate the individual steps that you might encounter in the real world enterprise; either separately or together. 

There are various tools and ways to make our changes, including via the old method outlined in Part 1.  But I’d be remiss if I didn’t confess that much of the time I use good ol’ DSMod.  Here’s what a DSMod line would look like to update our user:

dsmod user "cn=Jeremy Pavlov,ou=Demo,dc=CoretekServices,dc=local" -hmdrv H: -hmdir "\MyCompany.orgDFSPathHomes$username$"

…note that I used “$” (dollar sign), which is a cool way to have the DSMod command utilize the “Windows 2000 User Name”, or the “samAccountName” as the value for this special variable.

*Aside: Why do I keep mentioning the DSMod / DSAdd methods?  I’ll tell you.  It’s because much of the time, I use scripting to parse certain inputs and then generate other scripts that I can hand out to other administrators (yes, script-generating scripts).  And while I can’t be certain that everyone will be familiar with script editing and the PowerShell modules for Active Directory, I can be pretty sure they’ll have a command prompt and DSMod.  There are other reasons, but the rest mostly come down to preference and how the result files look, etc.  So there you go.

However, the new Powershell method with the ActiveDirectory module is pretty nice and easy for this task, too.  Here is the PowerShell equivalent to the DSMod command above: 

set-aduser -identity "jpavlov" -homeDrive h: -homeDir "\MyCompany.orgDFSPathHomesjpavlov"

…or at least its close, although this time I used the “ID” instead of the “Name”.  I think this deserves some closer examination…  So next week, I’ll spend a some time covering alternative inputs/methods to the above, before we move on to troubleshooting and validation, and then sum the whole thing up.

Next time…  A couple more ways to to get it done…  See you then!

 

Updated 20120923:  command syntax fix

Scripted Home Folder Management with PowerShell Pt. 3

2017-07-27T00:01:07+00:00 September 12th, 2012|Uncategorized|

In this post, I’m following up on Part 1 and Part 2 of this series where I showed you how to create users (and set a few attributes) with PowerShell.  Now that you have your user created and configured, I’m going to show you a bit about Home Folder creation and permission assignment.  Remember that all of these basics are leading toward a single, simplified, scripted elements method of managing Home Folders in the Enterprise.

So let’s create a folder.  Of course, you know how to do that already, so I won’t belabor the point too much.  Picking up where we left off in the last post, you already have a PowerShell session going, with network access to the shares where the folders will be created.  And since PowerShell has native access to the filesystem via its own object paths, you can actually skip the fancy stuff and just do a good ol’ md:

md \serverShare$JPavlov

…or if you’re using a DFS structure, something like this…

md \MyCompany.orgDFSPathHomesJPavlov

I know, I know.  That’s not PowerShell.  So if you really want to use the benefit of PowerShell, you would use the New-Item command like this (sticking with our DFS structure from above):

New-Item -type directory -path \MyCompany.orgDFSPathHomesJPavlov

Okay, great.  At this point, we have a folder, but no permissions yet for the person who will use it.  In order to set the permissions, we’ll stick with PowerShell and…

1.) Build a variable with the existing permissions with the Get-Acl command:

$acl = Get-Acl \MyCompany.orgDFSPathHomesJPavlov

2.) Add-on the permission we want (your permissions may vary!):

$rule = New-Object System.Security.AccessControl.FileSystemAccessRule("CoretekServicesJPavlov", "DeleteSubdirectoriesAndFiles, Modify, Synchronize", "ContainerInherit, ObjectInherit", "None", "Allow")
$acl.AddAccessRule($rule)

3.) And then stuff it all back on the folder with the Set-Acl command:

Set-Acl \MyCompany.orgDFSPathHomesJPavlov $acl

There you have it!  We’ve created the soon-to-be Home Folder for the user we created previously, and added permission we want.  So it’s out there if the user can browse around and find it…  But let’s help them out a little bit and deliver it as a mapped drive in the next post.

Next time…  Assigning this folder as the user’s Home Folder via the AD attribute.  See you then!

 

 

Scripted Home Folder Management with PowerShell Pt. 2

2017-07-27T00:01:07+00:00 September 5th, 2012|Uncategorized|

In this post, I’m following up on Part 1 of this series where I showed you how to create users (and set a few attributes) the basic way with Powershell.  Now, I’m going to show you an easier way to create users thanks to the new(ish) Powershell modules that came along in Windows Server 2008 R2.  In the up-coming parts of this series, we’ll continue on to Home Folder creation/management concepts and automation.  But for now, let’s get that user created…

To be honest with you, I have to admit that most of the time when I’m building a script loop and just need an easy output that looks nice, I’d just do the DSAdd tool like this:

dsadd user "cn=Jeremy Pavlov,ou=Demo,dc=CoretekServices,dc=local" -samId JPavlov -disabled no -fn Jeremy -ln Pavlov -pwd ChangeMe123! -mustchpwd yes

…but the future is here, and the future is PowerShell; and you and I have to get over it.  Powershell gives us better portability, variable management, etc., etc…  So onward and upward. 

And with recent versions of Windows 2008 R2, Microsoft provides the new “ActiveDirectory” module; making user creation/management activities as easy to do as the DSAdd/DSMod tools.  Here’s what I mean…

Open a Powershell session, and import the ActiveDirectory module like this:

Import-Module ActiveDirectory

Note: You need to have network access to an Active Directory server running AD Web Services for this module to work. 

Loading this module is the equivalent of launching the “Active Directory Module for Windows PowerShell” option on Windows 7 and Server 2008, but if you’re scripting you’ll want to make sure you load the module explicitly.  And, as a result, you have a ton of new AD tools available to you. 

You can get a good look at the majority of the new AD tools by using this command:

Get-Command *-AD*

Finally, using the New-ADUser command, we create that user with what is pretty much the equivalent of the DSAdd above (I used the same options to help clarify):

New-ADUser -Path "ou=Demo,dc=CoretekServices,dc=local" -SamAccountName "JPavlov" -Enabled $true -Name "Jeremy Pavlov" -GivenName "Jeremy" -Surname "Pavlov" -AccountPassword (ConvertTo-SecureString –AsPlaintext "ChangeMe123!" –Force) -ChangePasswordAtLogon $true

And that’s it!  You have a new user with your standard attributes set correctly.  I like this one-line method because it looks much cleaner when you are building import scripts that must be distributed to other folks, or when you want to insert some other command between each line (if you’re looping), etc.; it’s neat.

On a side note, there’s also a way to read in the contents of a formatted CSV, and pump it into the New-ADUser command; but my goal here is to show you concepts that ultimately can be combined into an multifaceted script.

Next time…  Home Folder creation and permission assignment.  See you then!

 

 

Load More Posts