Scripted Home Folder Management with PowerShell Pt. 1

2017-07-27T00:01:07+00:00 August 29th, 2012|Uncategorized|

I’ve been doing tons of scripting for the project on which I’m working lately.  And I thought it’d be cool to spend a few posts in a row covering a few base elements of PowerShell-based user and Home Folder management, and build up toward a script for user and folder creation/deletion that you can easily use. 

I don’t intend to get fancy with this; in fact, I intend to make is simple as possible, and maybe kick around a few alternative methods to do the same tasks.  My goal is not to teach PowerShell, but to show you you can script these things easily.

So join me on the journey!  But let’s get there in small steps.  We’ll start at the start, with user creation.  Open a PowerShell session, and let’s get to it…

In order for this article series to work, I have to make some assumptions: I’ll assume you have the proper rights, a test environment, the proper PowerShell modules, and a Windows 7 or Server 2008 R2 computer.

For this first method in Part 1, we are going to show you how to do it with just native Powershell, using the ADSI provider, without any additional Powershell modules.  It’s like learning how to do the work on paper before you use a calculator…  😉

First, set up a variable that opens an LDAP connection to the server, using the ADSI provider (note, “LDAP” is case-sensitive) and specifying the OU where we’ll be creating our new User object:

$MyConnection = 

Next, set up a variable that defines what you’re creating, along with a few critical attributes:

$MyObject = $MyConnection.create("User","cn=Jeremy Pavlov") 

Finally, the command to make it happen:


…and with that, the user is created in a “disabled” state.  So let’s fix that and set a password, using the same object and connection calls:


But, as you may or may not expect, the act of setting the password in the previous step also clears the requirement for the user to change the password at first login… but we definitely want the user to do that.  So let’s set it back with one final step:

$MyObject.pwdLastSet = 0

Okay, okay, I know what you’re saying, “…Man, that’s alot of work…”  And I’ll admit,this is the hard way.  So I’ll show you some easier ways in the next post.

(Updated 20120903; fixed syntax typos, split some content to next week’s post)

Next time…  A couple easier creation options…  See you then!



Coretek Services Summer Picnic 2012

2017-07-27T00:01:07+00:00 August 22nd, 2012|Uncategorized|

As another end-of-summer draws near, and with the 3rd annual Coretek Services Summer Picnic behind us, I just want to take a moment and thank everyone involved for the hard work it must have taken to put together, and the fun spirit it provided for all of us in attendance.  It really is nice to get the great folks at the core of Coretek together — along with family and friends — in such an informal and comfortable atmosphere. 

By the time the picture above was taken, many of us had broken out for a relaxed game of Mushball, gone off for a lazy pedal-boat ride around the pond, chased the kids off to the bounce house, etc.; all after having a wonderful spread of food, drink, snacks, and mostly-slushy slushies.

Then as the shadows grew long, and after some advice on extreme low-speed driving (“…it’s 15mph in the park folks; just go 10 to be safe…”) from the Sheriff Department, it was time to load up an arm-full or two of leftovers, and head off until next year. 

See you then…




XP DOS Batch File Date Tip…

2017-07-27T00:01:07+00:00 August 15th, 2012|Uncategorized|

A little while back, I wrote this tip on DOS Batch File Date Tips for Windows 7 and Server 2008.  I was asked for a clarification for XP as well (due to the minor differences), so I’m writing this as an alternate version of the same previous post.

No matter what people think, DOS batch scripts are just as alive and needed as ever.  And for all the tasks we create on Windows servers, we still commonly need to gather application output, rotate logs, etc.

So when running a script that exports results to a log/results file, I always prefer to date my file names for easy tracking and history.  My preferred date arrangement for filenames is the date in reverse format: YYYYMMDD, or 20120809.  And since the DOS date command isn’t as friendly or flexible as the Linux/Unix date command (with which you may easily format the output in myriad ways), it’s best to do the next-best thing: use the date *variable*.

Most folks don’t even know that your Windows system is keeping a real-time variable for the date, but it certainly makes sense that it would be necessary.  Go ahead, pull up a command prompt and type: echo %date%

…and on a Windows XP workstation, you’ll get a result like this: 08/09/2012

So what we need to do now is to utilize string manipulation, grab the date elements we want, and flip the order around to get the arrangement we need:
set todaysdate=%date:~6,4%%date:~0,2%%date:~3,2%

The structure above is this: There are 3 sections, all of which use the date variable.  The first section moves in 6 characters, and grabs 4 for the year.  The second starts at 0 (zero, the beginning) characters and grabs 2 (for the month), and the third moves in 3 and grabs 2 (for the day).  As a result, we have reverse-date!

Then we can set a variable to use the combined date variable in the filename like this:

set exportfile=C:tempexportmyexport-%todaysdate%.txt

…now just call the %exportfile% in your batch file when you redirect your output, and viola!!  Here’s what it looks like when you echo %exportfile%:






Summer Community Project

2012-08-08T23:42:07+00:00 August 8th, 2012|Uncategorized|

Recently about 40 Coretek employees, their friends, and family members, got together to help a family in need.  The family’s home had fallen into disrepair; serious health issues prevented them from being able to keep up with much-needed repairs and yard work. 

We assembled on a Saturday morning with our tools, work gloves, and supplies, to help out.  Braving the heat, humidity, and bugs, we helped to transform the place.  Some of the major jobs we were able to tackled:

– Installed a new back door for the house
– Cleared overgrown weeds, trees and grass
– Tilled the garden
– Painted the house and garage
– Power washed the vinyl siding
– Pruned several tree branches
– Dispose of refuse, like old shingles and garbage cans
– Spruced up flowerbeds with new mulch (lots of mulch!) and edging

…and other work items are still to come…

They say nothing worth doing is easy.  This project wasn’t easy, but it helped some folks that really needed it, and lifted the spirits of everyone involved.  I think we were all proud about what was accomplished; I know I am.



How to import the HKCU values of a different profile into your registry…

2012-08-01T23:01:31+00:00 August 1st, 2012|Uncategorized|

When troubleshooting an application installation issue — or an issue with the application itself — on the Windows operating system, it’s often necessary to view the registry.  The Windows registry holds a wealth of information and settings that determine just about everything related to how Windows operates; what it looks like, where and what users can access, and how applications behave.  If you know where to look, or what you’re looking for, this can be a pretty easy task; the “Find” function in the Registry Editor works pretty well.  However, if the issue is with registry keys under the HKEY_CURRENT_USER (HKCU) hive, it can be a challenge.  You see, the keys under the HKCU hive are unique to each users profile; thus, when you view the registry keys under HKCU in the Registry Editor, you are viewing the keys of the current logged-in user profile.

In an enterprise environment, applications are typically distributed via a configuration/distribution system such as Novell ZENworks Configuration Mannager (ZCM) or Microsoft System Center Configuration Manager (SCCM).  When software is installed through these systems, the application installers can be configured to run as the logged on user, under the system profile, or even as a “dynamic” administrator.  If the installer writes values to the HKCU profile they are written to the profile that ran the installer.  Thus, there is often need to view the HKCU values of a different user profile.  Adding more complexity to this, you may find yourself in a situation where the user profile under which the HKCU values are located doesn’t have access to the Registry Editor.  In this situation, you need to import the profile’s HKCU hive into your registry so you can view it.

The HKCU values for a profile are stored in a file called ntuser.dat, located in the root of the users’ profile.  On Windows 7 the path is c:users(profile)ntuser.dat.  There are a few ways to import the ntuser.dat into the registry with Registry Editor, but the quickest and easiest way I’ve found to do this is using the following command from an elevated command prompt:

reg.exe load HKLMTempHive c:users(profile)ntuser.dat

Now the HKCU values of the profile you imported can be viewed under a key called “TempHive” in the HKEY_LOCAL_MACHINE hive.

Hopefully, this will help you to resolve that issue you’re looking into!