A customer (via the customer liaison) discovered that even though they had set the Start­Run­No­HOME­PATH policy, they found “if the user creates a Notepad file, the file is searched in the user’s HOME directory, in contradiction of Start­Run­No­HOME­PATH policy,” I asked the liaison to confirm: “The steps you describe are rather vague. Are you saying that the problem occurs when the user opens the Run dialog and types Notepad filename.txt?” The customer liaison replied, “I believe the scenario is close to what you describe. The user opens the Run dialog, types Notepad, then types some text into Notepad and then does a Save As. I will confirm with the customer.” A few days later (the customer was on leave), the customer liaison provided the exact steps:

• Open the Start menu (Windows 7)
• Type Notepad to search the Start menu.
• When the Notepad program is found, click on it.
• Type some text.
• Perform a Save As. This operation is slow. Network traces show many accesses to the user’s HOME directory.

Okay, well, now that the steps are all carefully spelled out, it is clear what is going on. Or more accurately, it is clear what is not going on. The Start­Run­No­HOME­PATH policy controls the working directory when a program is run from the Start.Run dialog. Like it says in the KB article:

Symptoms

If you have a home folder set and you try to run a program by clicking Start and then clicking Run, Windows searches your home folder for the program before searching the path.

The article then goes on to describe how you can solve the problem if those are the symptoms you are trying to relieve. But those symptoms do not match the customer’s problem. The customer ran the program directly from the Start menu, not by going through the Start.Run dialog. Therefore, the KB article and the Start­Run­No­HOME­PATH policy do not apply.

Policies do what they are documented to do, not what you wish they did.