Happy Holidays from Coretek Services…

2012-12-19T23:51:27+00:00 December 19th, 2012|Uncategorized|

With the busy Holidays upon us, we at Coretek Services want to take a moment to wish all the Joys of the Season to all of our families, friends, loyal customers, and prospective customers…  …and even to each other!

Happy Holidays, everyone.  May the Season bring you the opportunity to receive everything you wish.

 

 

 

DFS Replication Validation Script…

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

The other day, while at the enterprise-level customer with whom I’m currently working, I ran into a situation where I needed to validate that certain parts of a DFS hierarchy were properly being replicated across the customer’s AD domain controllers.  As the administrators applied normal, routine DFS changes, the changes sometimes didn’t replicate properly across the enterprise — causing some segments of the DFS structure to not be visible or available. 

Apparently, the DFS problem was a result of using VMware guests as AD DCs.  I understand (from the customer) that a Microsoft hotfix is in the last stages of testing (at the time of this writing) and will be available for release “soon.”   It seemed that even though the DCs in question did not synchronize time with the ESX host upon which they reside, there is a default behavior in VMware Tools that assigns the host time value to the guest — at least up until the “do not sync” routine is processed during startup; after which the guest is then allowed to find its own time.  During this brief time window, the DFS Namespace service sometimes completes assembling its DFS target list and can find itself behind in time, relative to links it has been given by PDCE; which makes no sense to it, and it removes them from its listing.  And as a result, people can’t find their mapped drives or browse some of the DFS Tree.  (Note: I cannot take credit for this timing behavior investigation and results; and while I’d love to credit the folks who are due, I’m not permitted to.)  The customer remedied the situation with a temporary fix, but the real fix is the up-coming aforementioned patch.

Anyway, while the symptoms were being analyzed, I was working on other things and needed to work around the issue as much as possible while the solution was being chased.  So, I whipped up a simple little DOS script to go out and validate the top-levels of the DFS hierarchy across all domain controllers that carry them, in order to find out what would or wouldn’t be properly resolved.

For what it’s worth, I thought I’d pass the script along to you.  Here it is:

 

@SETLOCAL ENABLEDELAYEDEXPANSION
@set AdDomain=MyAdDomain.local
@set DirQuantity=17
@set DestPath=h:DcList.txt
@REM This requires elevated credentials, otherwise will fail...
@ipconfig /flushdns
@REM First we build the input file...
@nslookup %AdDomain% |findstr 
[0-9].*.[0-9].*|findstr /V /C:"Address: " > %DestPath% @ECHO As of 20121212, there should be %DirQuantity% DFS dirs on each server (actual, plus the "." and ".." items). @REM Now loop through the input file and check the DFS at the destination... @For /F "tokens=*" %%Q in (%DestPath%) Do @( @set MYDC=%%Q @set MYDC=!MYDC:Addresses: =! for /f "tokens=* delims=" %%A in ('dir /A:D \!MYDC!Corp ^|findstr /C:"Dir(s)"') do @set MYDIR=%%A for /f "tokens=* delims= " %%G in ("!MYDIR!") do @set MYDIR=%%G @REM Options A: Use this line if you wish to see all DFS sources: @ECHO For: !MYDC! !MYDIR:~0,9! @REM Option B: Use this line if you wish to see only those in violation @REM (note: there's a space and tab separator for spacing alignment): @REM @ECHO For: !MYDC! !MYDIR:~0,9! |findstr /V /C:"%DirQuantity% Dir(s)" )

What it does:

The script builds a domain controller list in a static, external file, then iterates through the list, attempting to quantify the available DFS path branches against a numeric count that you supply in another variable.  I provided two different “ends” to the script (one of them commented out), in order to give you a couple different ways to present the results.  Make sure to “set” the variables in the first few lines, to your locally-relevant information; especially the number of *expected* DFS hierarchies.

Of course, I wanted to write it to do more, but I pretty much ran up against the limits of what I *should* do in a DOS script.  I’ll make another version in PowerShell some day that iterates down the hierarchy and validates the entire structure, instead of just the top level… 

…Unless you beat me to it…  😉

There you go; enjoy!

🙂

 

 

Don’t Rename Vendor-Provided .MSI Files…

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

When packaging an application for deployment in the enterprise, you must also identify it’s dependencies — additional software required for the application to successfully install and function.  Often times these dependencies are redistributable run-times for Microsoft Visual Studio.  These redistributables are so common, they are often packaged separately and “chained” to the dependent application.

This method of installing dependencies usually works pretty well; the deployment tool determines whether to install the package, based on it’s previous installation history.  If, however, the dependency was installed outside the deployment tool’s domain — by an application a user downloaded, for example  — you may encounter errors when the dependency is re-run; this could fail your entire application package chain.

Fortunately, many (but not all — always test!) Microsoft redistributables, like “Visual C++ 2008 SP1 Redistributable Package (x86)“,  are authored so that they can install over an existing install — without actually modifying anything or going into “maintenance mode”.  The screen shot below illustrates that the Windows Installer services runs the .MSI package, and verifies that it’s already installed with the same product code, package code, component IDs, etc., and simply exits without modifying the existing install.  This can be a packager’s saving grace in an unpredictable enterprise environment.

 

Wise Compatibility Key

 

Recently, however, I came across an issue with my philosophy of simply letting the redistributable re-run over an existing install. 

A package I had developed started failing.  After checking the logs, I noticed the failure occurred during the install of the dependent runtime  “Visual C++ 2008 SP1 Redistributable Package (x86)”.  The runtime install was exiting with a Windows Installer general failure code of “1603”. 

A look at the detailed installation log shows a more confusing error: “Error 1316.  A network error occurred while attempting to read from the file: C:Userspopper1Desktopvcredist_x86vc_red_x86.msi”.

With some help from my co-worker (Windows Installer guru Urb Bernier) we were able to find the issue: the .MSI that originally installed the Visual C++ runtime was extracted from the vendor’s .EXE bootstrap and…RENAMED!  A grievous offense in the application packaging world!  Well, that may be a bit dramatic, but it certainly violates all “best practices”.  When extracted from the vendor provided setup file “vcredist_x86.exe”, the .MSI is named “vc_red.msi”.  Perhaps the packager may have renamed the file in order to distinguish the 32-bit setup file from the 64-bit setup? 

The error “1316.  A network error occurred while attempting to read from the file: C:Userspopper1Desktopvcredist_x86vc_red_x86.msi” is Windows Installer’s way of saying it can’t access the file in the path; the “cached” path to the .MSI that originally installed the Visual C++ runtime.

You see, the issue is that you can rename the .MSI, install it successfully, re-run it successfully, and uninstall it successfully; provided you do all of these actions using the renamed .MSI.  If, however, the actual vendor install runs on that same machine, whether from the bootstrap .exe or from the extracted .MSI, it will exit with a Windows Installer general error code “1603”.

Packaging applications can sometimes be a frustrating task; because no matter how much forethought and care you put into your package, it can always be thwarted.  To be fair, I guess the same could be said for just about any other job.  

However, I hope this example illustrates why you should not rename vendor provided .MSI files!