Server 2003 EOS, Part 3…

2017-07-27T00:01:00+00:00 February 12th, 2015|Uncategorized|

(Please see Server 2003 EOS, Part 1, and Part 2 for background)

Well, folks, now the Server 2003 EOS is just 153 days away as I type this in early February…  And don’t tell me you’re still running Exchange 2003 or 2007 on that Server 2003, are you?!?

Well, it’s a good thing that Chris Shalda and I just finished presenting the second part of our 4-part webinar series, “The Windows Server 2003 Comfort Trap”.   Part 2 is all about Exchange, and you can watch it embedded below in this page or directly here.  Chris goes into pretty good detail about why you should be concerned about EOS and your Exchange server, and some tips and approaches to help you get started in preparing.  

So grab some popcorn and cocoa, and watch the movie!  It’s about 40 minutes long, and could be the first step in helping you out of the Comfort Trap!

Update: Also, the other Sessions can be seen here:

Thanks to all that attended the live webinar!  And for those that stuck with us even though we had some audio difficulties at the beginning.  😉

In the upcoming sessions in this series, we’ll be bringing on more special guests from Coretek to tell their stories and give great insight.  I know I’m looking forward to it!  See you then…

 

Server 2003 EOS, Part 2…

2017-07-27T00:01:00+00:00 January 28th, 2015|Uncategorized|

(Please see Server 2003 EOS, Part 1 for background)

Well, folks, the Server 2003 EOS is just 167 days away as I type this in late January…  What is the “EOS” you ask?  I’m glad you asked…

I just finished presenting the first part of our 4-part webinar series, “The Windows Server 2003 Comfort Trap”.  Part 1 is called “Foundations”, and you can watch it at this link, and its also embedded below in this page. I go into pretty good detail about what the EOS is, why you should be concerned, and some tips and approaches to help you get started in preparing.  

So grab some popcorn and cocoa, and watch the movie!  It’s only about 33 minutes long, and might just be your first step in getting yourself out of the Comfort Trap!

Update: By the way, the other Session can now also be seen here:

Thanks to all that attended the live webinar!  And thanks to all those that pointed out that I have the wrong date in the first slide… I promise to have that fixed for the next session.  😉

Speaking of which, in the upcoming sessions in this series, we’ll be bringing on other special guests from Coretek to tell their stories and give great insight into the areas which are their strengths.  I know I’m looking forward to it!  See you then…

 

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]

How to fix Ownerships and Inheritance on NTFS file systems, Pt. 2…

2017-07-27T00:01:03+00:00 September 18th, 2013|Uncategorized|

For background on this post, make sure to see Part 1, here

Picking up where we left off in Part 1, recall that I had a set of folders that were copied with original source permissions, and as a result, had broken permission “inheritance”.  The copy also brought over the various ownerships, which I was seeking to replace with the local “Administrators” group, according to standard practice of the customer.

So in Part 1, I had written a DOS batch script to loop through the folders and 1.) force down ownership in the new folder sub-structures (in order to follow company standard and be able to seize control of them), and 2.) re-apply inheritance of the administrative permissions from the folders above.  While I’d like to think I accomplished this swimmingly with my batch file, the truth is that it really needs to be in PowerShell in order to satisfy the needs of the team (future-proofing, portability, and such).

Let’s step through the PowerShell version now; but watch carefully because even though it is the same in principle as the DOS batch script in Part 1 (same enough to be worthy of comparison), it actually is a tad different in a few of the steps.

First, we clear the screen, set some variables, and clean up any files from the last run:

clear
$StartDate = date
Write-Host "Setting variables..."
$PARENTDRIVE = "S:"
$PARENTFOLDER = "Apps"
$PARENTPATH = "$PARENTDRIVE$PARENTFOLDER"
$LOCALPATH = "c:temp"
$TAKEOWNLOG = "$LOCALPATHtakeown-FixOwnerships.log"
$ICACLSLOG = "$LOCALPATHicacls-FixInheritance.log"
$ICACLSSUMMARYLOG = "$LOCALPATHicacls-FixInheritance-Summary.log"
Write-Host "Cleaning up log files from previous run..."
del $TAKEOWNLOG
del $ICACLSLOG

Now, with this PowerShell version of the script, I don’t need to write my lists out to a temp file for later processing (like I did with DOS in Part 1); I just dump it all into objects in memory.  Far more efficient!  Like so:

Write-Host "Creating Listing..."
$FolderListing = Get-ChildItem $PARENTPATH

Then, we hit the real work part of the script, where we loop through the folder listing, decend though and fix all the ownerships and inheritance.  This part is actually almost the same as the DOS batch script, actually, except that it’s more… um… awesomer:

Write-Host "Process listing..."
foreach ($FolderItem in $FolderListing)
{
  Write-Host "Fixing ownership: $PARENTPATH$FolderItem"
  Write-Output "Fixing ownership: $PARENTPATH$FolderItem" | Out-File $TAKEOWNLOG -append -encoding Default
  takeown /f $PARENTPATH$FolderItem /R /A /D Y  | Out-File $TAKEOWNLOG -append -encoding Default
  Write-Output "" | Out-File $TAKEOWNLOG -append -encoding Default
  #
  Write-Host "Fixing inheritance: $PARENTPATH$FolderItem"
  Write-Output "" | Out-File $ICACLSLOG -append -encoding Default
  Write-Output "Fixing inheritance: $PARENTPATH$FolderItem" | Out-File $ICACLSLOG -append -encoding Default
  ICACLS $PARENTPATH$FolderItem /inheritance:e | Out-File $ICACLSLOG -append -encoding Default
}

And finally, we create a summary log and create some closing comments before cleaning up:

Write-Host ""
Write-Host "Creating summary log..."
Select-String -pattern "Failed" $ICACLSLOG | Out-File $ICACLSSUMMARYLOG -encoding Default
Write-Host ""
$EndDate = date
Write-Host "Started: $StartDate"
Write-Host "Ended:   $EndDate"
Write-Host ""
Write-Host "...Complete!"

So that’s about it, really.  Note that I’m using the -encoding Default flag  at each Out-File so the file gets written in ANSI (on my system) instead of UniCode.   I don’t know about you, but I can’t stand dealing with UniCode files for text parsing and such.

And in case you prefer it in one contiguous list, here ya go:

clear
$StartDate = date
Write-Host "Setting variables..."
$PARENTDRIVE = "S:"
$PARENTFOLDER = "Apps"
$PARENTPATH = "$PARENTDRIVE$PARENTFOLDER"
$LOCALPATH = "c:temp"
$TAKEOWNLOG = "$LOCALPATHtakeown-FixOwnerships.log"
$ICACLSLOG = "$LOCALPATHicacls-FixInheritance.log"
$ICACLSSUMMARYLOG = "$LOCALPATHicacls-FixInheritance-Summary.log"
Write-Host "Cleaning up log files from previous run..."
del $TAKEOWNLOG
del $ICACLSLOG
Write-Host "Creating Listing..."
$FolderListing = Get-ChildItem $PARENTPATH
Write-Host "Process listing..."
foreach ($FolderItem in $FolderListing)
{
  Write-Host "Fixing ownership: $PARENTPATH$FolderItem"
  Write-Output "Fixing ownership: $PARENTPATH$FolderItem" | Out-File $TAKEOWNLOG -append -encoding Default
  takeown /f $PARENTPATH$FolderItem /R /A /D Y  | Out-File $TAKEOWNLOG -append -encoding Default
  Write-Output "" | Out-File $TAKEOWNLOG -append -encoding Default
  #
  Write-Host "Fixing inheritance: $PARENTPATH$FolderItem"
  Write-Output "" | Out-File $ICACLSLOG -append -encoding Default
  Write-Output "Fixing inheritance: $PARENTPATH$FolderItem" | Out-File $ICACLSLOG -append -encoding Default
  ICACLS $PARENTPATH$FolderItem /inheritance:e | Out-File $ICACLSLOG -append -encoding Default
}
Write-Host ""
Write-Host "Creating summary log..."
Select-String -pattern "Failed" $ICACLSLOG | Out-File $ICACLSSUMMARYLOG -encoding Default
Write-Host ""
$EndDate = date
Write-Host "Started: $StartDate"
Write-Host "Ended:   $EndDate"
Write-Host ""
Write-Host "...Complete!"

Enjoy!

 

 

How to fix Ownerships and Inheritance on NTFS file systems, Pt. 1…

2017-07-27T00:01:03+00:00 August 28th, 2013|Uncategorized|

Following up on Matt’s post last year, and my post about a similar-but-different situation…  I’m just taking Matt’s original notions to the next level, and making the script he described.

It all started after we ran into a situation where someone was migrating some data from one Windows server to another along with the NTFS permissions (using a 3rd-party copy tool).  It was soon discovered that all the permission inheritance was blocked at the point of the copy, and all the ownerships were set to the original owners (not desired in this case).  The company policy dictated that the administrative permissions from the parent folder must flow down, and that all ownerships for files and folders were set to the Administrators group. 

So, I needed to whip up a little script to fix the permission inheritance for all the new subfolders on the destination under one parent folder, and reset the ownerships to the Administrators group for each subfolder as well.

A couple important criteria I had to work around was that I write it so that it only works on the migrated subfolders, so I don’t affect the parent folders under which these new folders were copied (which actually had *intentionally* blocked inheritance and might possibly have intentional alternate owners in some situations).

Well, since all folders ended up in the same destination parent, I naturally wrote a simple little DOS batch script to fix these.  Why DOS batch, you say?  I don’t know, honestly.  Sometimes when I’m thinking through a Linux/Unix scripting situation, I start thinking of it in bash, and change to Perl when I realize it’s too complex.  And similarly in Windows-based environments I start thinking in DOS batch, and then switch to PowerShell when it gets too complex.  Just an old habit that’s hard to break, I guess.

So, walking through the main sections of the script…

First, we do initial setup, set variables for output files and such, and delete the files from the last run of the script (since it would likely be run repeatedly as a maintenance tool):

@ECHO OFF
@cls
1>&2 Echo Setting variables...
SET PARENTDRIVE=S:
SET PARENTFOLDER=Apps
SET PARENTPATH=%PARENTDRIVE%%PARENTFOLDER%
SET LOCALPATH=c:temp
SET FOLDERLIST=FolderList.txt
SET TAKEOWNLOG=takeown-FixOwnerships.log
SET ICACLSLOG=icacls-FixInheritance.log
SET ICACLSSUMMARYLOG=icacls-FixInheritance-Summary.log
1>&2 Echo Cleaning up log files from previous run...
@del %LOCALPATH%%FOLDERLIST%
@del %LOCALPATH%%TAKEOWNLOG%
@del %LOCALPATH%%ICACLSLOG%
@del %LOCALPATH%%ICACLSSUMMARYLOG%

Then, we create a listing file of the top-level folders, and store them in a file (with quotes):

1>&2 Echo Creating Listing...
@FOR /F "tokens=*" %%a in ('"dir %PARENTPATH% /A:D /B"') do @echo "%%a">>%LOCALPATH%%FOLDERLIST%

Now we change to the destination folder, and begin processing.  This is really the meat of the script.  This is where we use takeown to set Adminstrators group ownership to each folder heirarchy, and ICACLS to force permission inheritance (for administrator permissions from the parent):

1>&2 Echo Changing to %PARENTDRIVE% and %PARENTFOLDER%...
%PARENTDRIVE%
CD %PARENTFOLDER%
1>&2 Echo Process listing...
@For /F "tokens=*" %%Q in (%LOCALPATH%%FOLDERLIST%) Do @(
1>&2 Echo Fixing ownership: %%Q
@takeown /f %%Q /R /A /D Y >> %LOCALPATH%%TAKEOWNLOG%
1>&2 Echo Fixing inheritance: %%Q
ECHO Analyzing: %%Q >> %LOCALPATH%%ICACLSLOG%
ICACLS %%Q /inheritance:e /T /C >> %LOCALPATH%%ICACLSLOG%
)

And here is where we wrap it up.  I provide a brief summary report, and say goodbye:

1>&2 Echo Creating summary log...
FindStr /I /C:"failed" /C:"analyzing" %LOCALPATH%%ICACLSLOG% > %LOCALPATH%%ICACLSSUMMARYLOG%
1>&2 Echo ...Complete!

Now here is the whole script again, in once piece:

@ECHO OFF
@cls
1>&2 Echo Setting variables...
SET PARENTDRIVE=S:
SET PARENTFOLDER=Apps
SET PARENTPATH=%PARENTDRIVE%%PARENTFOLDER%
SET LOCALPATH=c:temp
SET FOLDERLIST=FolderList.txt
SET TAKEOWNLOG=takeown-FixOwnerships.log
SET ICACLSLOG=icacls-FixInheritance.log
SET ICACLSSUMMARYLOG=icacls-FixInheritance-Summary.log
1>&2 Echo Cleaning up log files from previous run...
@del %LOCALPATH%%FOLDERLIST%
@del %LOCALPATH%%TAKEOWNLOG%
@del %LOCALPATH%%ICACLSLOG%
@del %LOCALPATH%%ICACLSSUMMARYLOG%
1>&2 Echo Creating Listing...
@FOR /F "tokens=*" %%a in ('"dir %PARENTPATH% /A:D /B"') do @echo "%%a">>%LOCALPATH%%FOLDERLIST%
1>&2 Echo Changing to %PARENTDRIVE% and %PARENTFOLDER%...
%PARENTDRIVE%
CD %PARENTFOLDER%
1>&2 Echo Process listing...
@For /F "tokens=*" %%Q in (%LOCALPATH%%FOLDERLIST%) Do @(
1>&2 Echo Fixing ownership: %%Q
@takeown /f %%Q /R /A /D Y >> %LOCALPATH%%TAKEOWNLOG%
1>&2 Echo Fixing inheritance: %%Q
ECHO Analyzing: %%Q >> %LOCALPATH%%ICACLSLOG%
ICACLS %%Q /inheritance:e /T /C >> %LOCALPATH%%ICACLSLOG%
)
1>&2 Echo Creating summary log...
FindStr /I /C:"failed" /C:"analyzing" %LOCALPATH%%ICACLSLOG% > %LOCALPATH%%ICACLSSUMMARYLOG%
1>&2 Echo ...Complete!

But you know what?  That’s not good enough for Matt and me.  Nope, Matt basically insisted that it had to be done in PowerShell after all.  So of course I did that too, and I’ll put that up next week.  Why PowerShell you say?  I don’t know… Why not?

😉

 

 

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? 

😉

 

 

 

How to script “Ownership” of NTFS File Systems…

2017-07-27T00:01:07+00:00 July 25th, 2012|Uncategorized|

There’s a time in every IT professional’s life where he or she will need to “Take Ownership” of files and folders that reside on an NTFS File Server (or in larger cases with hundreds or thousands of servers) in a Windows Server 2008 R2 or Windows 7 environment.  I’m sure most IT professionals already know how to do this in the Windows Explorer GUI … but what if your task at hand required that you script this process to run during a limited window of time given during a server migration, and you had to minimize the amount of “clicks” as well as the amount of time spent on multiple servers?  

I was recently assigned to a project very similar to the scenario described above; and after a little research, I stumbled upon a little-known Microsoft tool called ‘takeown.exe’ that has been shipping with Microsoft Server products since Windows Server 2003.  Within minutes of discovering ‘takeown.exe’ I had a script written and I was running it in my test environment with positive results.  This shows how simple the tool really is!

Below is the usage example as seen from the command line ‘takeown.exe /?’:

TAKEOWN 
[/S system [/U username [/P
[password]]]] /F filename [/A] [/R [/D prompt]]

Below is my personally recommended example: 

TAKEOWN.exe /F C:MyFolder /R /A

 

As expressed above, my suggestions are to use the /F (to specify the folder to apply ownership on), the /R switch (as in “recursive” which mean to apply to all child objects, sub-folders and files) and the /A switch (which gives ownership to the “Administrators” group instead of the currently logged in user).  And while I didn’t use the /D switch in the above example, it may be necessary to use the “/D Y” to avoid being prompted in cases where the user ID running the command does not have rights to list the folders.   

You can also reference additional parameters by typing in ‘takeown.exe /?’ from the command prompt on any Windows Server 2008 R2 server or Windows 7 machine.

 

Easy Mass-Export of Novell eDirectory Login Scripts, Pt. 2

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

For reference, please see Part 1 of this article here, where I explain the back-story and Login Script Tools Gadget discovery.

Now that the login scripts are exported, you can parse the files for either:

  1. The login script entries that you are trying to mitigate (to avoid drive letter conflicts)
  2. The login script changes you are trying to track (during the migration process)

A simple way to capture the existing mapping commands that you want to find (for planning, migration, mitigation) is to use a standard Windows command like this (it is assumed that all exported login script exports have a *.txt extension):

findstr "J:= N:= S:= U:= Z:=" *.txt > DriveLetterViolations.wri

Here’s another example that excludes all REMarked-out lines (assuming traditional remark strings), since you probably don’t want to track those mappings you’ve REMmed out during the migration:

findstr /I "J:= N:= S:= U:= Z:=" *.txt | findstr /I /V /C:^* /C:^; /C:^REM > DriveLetterViolationsNonRem.wri

Or just one letter at a time per report:

findstr /I /L /C:"map J:=" /C:"map root J:=" *.txt | findstr /I /V /C:^* /C:^; /C:^REM > Violations-L.wri
findstr /I /L /C:"map N:=" /C:"map root N:=" *.txt | findstr /I /V /C:^* /C:^; /C:^REM > Violations-M.wri
findstr /I /L /C:"map S:=" /C:"map root S:=" *.txt | findstr /I /V /C:^* /C:^; /C:^REM > Violations-T.wri
findstr /I /L /C:"map U:=" /C:"map root U:=" *.txt | findstr /I /V /C:^* /C:^; /C:^REM > Violations-X.wri
findstr /I /L /C:"map Z:=" /C:"map root Z:=" *.txt | findstr /I /V /C:^* /C:^; /C:^REM > Violations-V.wri

Note that the output files are intentionally not named with a *.txt extension, so that they will not be included in any subsequent runs of the commands (which are parsing *.txt files).

Also, in preparation for performing the final migration, it is often necessary to create checklists of locations where the mapping commands to the older servers are.  Here is an example command from an imaginary migration, where it looks for any mappings that point to OLD_FS1 or OLD_FS2:

findstr /I /C:"OLD_FS1" /C:"OLD_FS2" *.txt | findstr /I /V /C:^* /C:^; /C:^REM  > mappingsToOldServers.wri

 I hope that helps you in your migration!

🙂

 

Updated 20120326 for improved findstr filters.

Easy Mass-Export of Novell eDirectory Login Scripts, Pt. 1

2017-07-27T00:01:08+00:00 November 9th, 2011|Uncategorized|

The Challenge

A little while back, I was working on a project that involved migrating from Novell NetWare and eDirectory to Windows Server 2008 R2 and Active Directory, with a large handful of eDirectory login scripts that were to be edited throughout the migration process.  We mostly just wanted to keep track of the changes in the scripts as the migration occurred, but we also wanted to rapidly re-validate the scripts in case other changes were being made by other staff members.  I had access to a licensed software tool that mostly accommodated this purpose; but it was cumbersome, and I wished for something simpler and more effective.

By the time I had moved on to my next customer engagement, I was once again faced with the need for such a piece of software.  However, this time it would be on a much larger scale; this time I would be needing the tool to inspect and track around 20 different eDirectory trees, with up to hundreds of login scripts per tree.

The Wager

Around the same time, Donte (fellow Coreteker extraordinaire) was working on a similar customer project, and commiserated with me on the phone one evening about the lack of an efficient, affordable, effective eDirectory login script mass-export tool.  We decided on that call that we would have a little personal bet to find one that was better than the tools we had; and guess what… 

The Winner

…I win! 

At some point, I suddenly remembered a set of lectures I had attended in the past by Peter Kuo of DreamLAN Consulting, and recalled that they had produced a tool for management of Novell login scripts.  I managed to locate their “xSCRIPT” tool on Novell’s Cool Solutions; and though it appeared that it was created over a decade ago as part of the “NDS Toolkit”, I decided to contact them to see if it was still available and supported. 

Fortunately, Peter immediately responded.  He informed me that while xScript is still available, he wondered if I would be interested in a newer LDAP-based version that is faster, more flexible, and more robust.  I was certainly interested! 

The Deets

It is called the Login Script Tools Gadget, and is part of a larger LDAP Gadget suite of products.  Peter provided a trial version to allow me to prove that it was the perfect tool for the job.  The price is amazing at around $50 per eDirectory tree!  Even better, since the customer had more than 15 eDirectory trees, we were permitted to purchase a “Site” license, at around $500 (still amazing).

We have installed it, used it, and loved it.  It has been a lifesaver in the trenches of the migration from NetWare to Windows Server!

And now my next problem…  I need to try and remember what I had bet Donte, in order to collect whatever my prize is…

😉

Now you know the back-story, and the information about the helpful software; in a future post, I’ll reveal some of the cool ways we used it.

Enjoy!