Fundamental Software Solutions

We found another solution while deploying Windows 7 that we could not find information anywhere on the internet.  Our client wanted an aggressive power management strategy for their desktop computers; that is they would be forced to try and save power across their fleet of client, desktop computers.

When building the systems, we found that the Windows 7 Aero interface wouldn't work.  We also couldn't run winsat (the experience index calculation tool) from either the command line, nor the control panel.

After searching through tons of blog entries and support forum requests, we found the problem in our own log.  The power settings couldn't be applied - and winsat exited with some other error from WMI indicating that an instance of an object could not be created.

 After turning off the GPO, everything started to work again.

I had a couple of intermittent problems while supporting a client that I couldn't find any information on, anywhere.

The problem manifested itself when they plugged in their mobile phone to their computer.  In XP, using ActiveSync, or using Windows Mobile Device center in Vista, and Windows 7.  Before they plugged in their mobile, they could use the internet browser on their computer, through a proxy auto-configured with WPAD.DAT, and after, they couldn't.  The web seemed to just "stop" resulting in a "cannot connect" error at the web proxy server, every time.

I incorrectly focused on ActiveSync at first - since that was the point of contact that caused the failure, and found that although it installed a network driver to communicate with the phone - it didn't seem to matter what the network settings were.

Finally, while working with the WPAD.DAT (auto-configuration script) I found that the actual call to myIpAddress() was returning an auto-configured address, and not a DHCP address on the connected subnet.  Since I was using shExpMatch(myIpAddress(), "192.168.1.*") to test the validity of the local network - the WPAD was incorrectly configured to go DIRECT through the firewall, which wasn't allowed.

Instead, I added this to WPAD.DAT

 if(shExpMatch(myIpAddress(), "169.254.*"))
  return "PROXY 192.168.1.1:8080";

So, careful using myIpAddress() in WPAD.DAT, unless you account for the Windows Mobile IP Address to be returned in myIpAddress().

Windows Desktop Search 4.0 is a pretty cool little piece of software; it indexes a computer and allows free-text searching of file contents and properties.  In fact, it replaces a lot of technologies that would have cost thousands of dollars.  However, windows Desktop Search is best run on the computer where the data resides and not necessarily over the network.  (Think of a corporate situation where tens or hundreds of systems are trying to index the same server... eek!)

So how do you get the results to the client desktops when you need them?  Well, as Microsoft always tends to support with their products - there is a way to query WDS pragmatically.

This project really came out of a client deployment of Windows 7.  Using Federated Search and the Windows 7 Start Menu Search functions, we wanted to take two data servers (with WDS installed on each) and query them.  Since Windows 7 is polite enough to use OpenSearch to connect and retrieve data from search targets- there was a quick and half-day solution we could implement from end-to-end.  Not only did we not have to write a search client application for the service, but we didn't have to worry about COM permissions calling the server from many low-priv client desktops.

So, how do we get the results?  A lightweight WDS Web Server application could be added to the IIS server on the machine doing the indexing - and we created a small piece of code to do just that.  It installs a WDSSearch web folder, which you can query using this .searchConnector-ms file.

<?xml version="1.0" encoding="UTF-8"?>
<searchConnectorDescription xmlns="http://schemas.microsoft.com/windows/2009/searchConnector">
<description>Search WDS Server for some keywords</description>
<isSearchOnlyItem>true</isSearchOnlyItem>
<isIndexed>true</isIndexed>
<includeInStartMenuScope>true</includeInStartMenuScope>
<domain>http://mydomain.com</domain>
<supportsAdvancedQuerySyntax>true</supportsAdvancedQuerySyntax>
<templateInfo>
<folderType>{8FAF9629-1980-46FF-8023-9DCEAB9C3EE3}</folderType>
</templateInfo>
<locationProvider clsid="{48E277F6-4E74-4cd6-BA6F-FA4F42898223}">
<propertyBag>
<property name="OpenSearchShortName">
<![CDATA[Archived Files]]></property>
<property name="OpenSearchQueryTemplate">
<![CDATA[http://myserver.mydomain.com/WDSSearch/Search.ashx?Search={searchTerms}&Type=File]]>
</property>
<property name="MaximumResultCount" type="uint32">
<![CDATA[512]]>
</property>
</propertyBag>
</locationProvider>
</searchConnectorDescription>

We placed the file in c:\program files with a different installer, and then hooked up group policy to push the settings and make the search installable on the Start menu.  However, you could put the file on the desktop and just double-click it when you want to search that location, too.

There is one other problem related to doing the indexing on the server; the file locations are relative to the server and not necessarily the client.  We handle this by re-mapping file locations on the fly as results are returned.  For that, in the WDSSearch\App_Data folder, we have a replacements.xml file which contains Regular Expression replacements that can be customized:

<?xml version="1.0" encoding="utf-8" ?>
<FSSI-FedSearch>
<Configuration>
<Channel Title="FSSI Federated Desktop Search Source" Link="http://mydomain.net/"/>
<Limits MaxResults="250" />
</Configuration>
<PathOperation>
<Operation Match="^[A-Za-z]:\\Management\\" Mode="Skip"/>
<Operation Match="^[A-Za-z]:\\Projects\\" Mode="Replace" ChangeTo="O:\"/>
</PathOperation>
</FSSI-FedSearch>

The WDSSearch code searches the PathOperation node for any Operation child nodes.  It applies each to the file in question and either replaces or skips the file/location type.    If it skips the file, it isn't displayed in any result RSS feed.

For a file on the server indexed as "E:\Management\Staff.XMLX', the first Operation node tells WDSSearch to eliminate that from the results set.  However, anything like "E:\Projects\2001-99922-1112\Proposal.docx" will get changed on the fly to "o:\2001-99922-1112\Proposal.docx" by the Match and ChangeTo XML Attributes.  Of course, the above example assumes that the clients are mapped to drive O:\.  You could also use:

        <Operation Match="^[A-Za-z]:\\Projects\\" Mode="Replace" ChangeTo="\\MyServer\ArchivedData\"/>

By the way, the available Modes for the Mode XML Attribute are Currently 'Skip' and 'Replace'.  The Match XML attribute is a .NET Regular expression, and is passed through Regex.Replace.  The ChangeTo is what the matches are replaced with.

You can even publish things over the web with this method; like:

        <Operation Match="^[A-Za-z]:\\Projects\\" Mode="Replace" ChangeTo="http:\\MyServer.MyDomain.Com\PublicDownload\"/>

Just turn on directory browsing and web-share that folder ... although you will want to secure the data by ACL or some other means to protect it from anonymous activity.

You can modify the replacements.xml file at any time, and the next search request will automatically detect the file-modification time has changed and re-load the XML file and configuration.

Below is the installer for the V1 IIS site; The sample even properly passes complex search terms like AND and "PHRASE THAT MUST BE INCLUDED" and not searches like (-WORD) to the WDS query engine.

Download for Windows Desktop Search 04.00.6001.503:  WDSSearchPublic.msi (414.00 kb)

We have been a part of deployment projects with Windows XP and Windows 2000 on very large scales in the past, and now are getting our hands dirty with Windows 7.  This deployment is for a SMB only of about 40 computers, and so far, we are very impressed.

Microsoft has come a long way with the deployment process of their operating system.  At first, understanding the steps and deployment stages can be daunting, but a quick read of the unattended settings using the documentation provided with the System Image Manager makes things a breeze.  The WIM format and ImageX tools allow us to overlay application data onto the drive in layers, instead of creating drive images and then copying loose files over-top. 

The goal with any deployment project is to minimize deployment time on the day-of, and there is some time spent with the WIMs that I think could be faster, but it is fast enough for a complete corporate install in about 2 days with only 2 techs on about 40-60 computers.  We found a way to do this without the purchase of any third party tools, also!

... Does anyone but me remember those weekends being stretched to the limit installing Windows XP by hand, and then installing all the applications afterward?

The time savings actually makes this deployment pay for itself in the long run, too.  New computers introduced into the company can be completely generated in 30 minutes.  No more ordering from your computer supplier and then stripping all the settings that you couldn't remove with Group Policy.

In conclusion of this brief article, anyone having to install an operating system (or returning an operating system to a base state) should be thinking automated and unattended deployment first - especially if 5 or more computers are involved - it is simple, cheap and very reliable.

I know that when developing software for Windows Vista, several companies out there are still adding something like "If UAC is turned on, you will want to ... <insert steps to turn off UAC here>" in their manuals.

Here is something worse that I had the fun of working with last week, Credit card processing software.  The software connects using a socket to a port at the bank and allows a company to process credit card transactions.  Pretty simple, really.  However, even the banks can't seem to get security right on such a simple application.  (So far, a week's worth of work in our labs could yield a similar product with proper security - it isn't rocket science...)

From my day of working with the installer, application and tech support - the application fails the following of my security checks (and we haven't even been able to get it running yet on the system - and the Bank support is dumfounded about it, of course...)

1. The support person on the phone asked me to allow users to read and write the whole program directory.  (It self-updates apparently, and stores all of its transaction files in the same directory.
   
2. I asked if I should open TCP or UDP port xxx on the corporate firewall for the application to communicate.  The result was: "Just to be safe, open them both."  another technician said "It shouldn't matter" and a third seemed to know just TCP.

The first issue is Windows programming 101.  Directory permissions (and almost every resource controlled with a HANDLE) are set up to secure data and the operating system.  In this case, the program data itself.  A malicious user could, when the program directory is marked read/write - add a new .EXE that would create a keyboard hook, launch the real .EXE and - have access to ALL the credit card data entered.  The accounting department would never know it happened, and nor would the directors of the company (who signed the "we are responsible for all transactions" contract...) 

Now the network traffic isn't such a problem.  There has only been one instance that I can recall of a staff member port-scanning a firewall to see what ports they could connect outward with and use that port to proxy web traffic.  But still, a bank should know the absolute minimum configuration without any question.  The software already has some requirements that make it seem like they are paying attention, claiming within the documentation that both antivirus and a firewall are necessary.

I guess you have to use them.  You have to detune your system, end of discussion.  I can't receive credit card numbers and process them without having some bank connection.  And, I have to de-tune my systems to allow unsecured access to the programs, yet even sign a document saying that I will keep everything secure.

Banks: 1, Customers: 0