A customer (via the customer liaison) discovered that even though they had set the
StartRunNoHOMEPATH policy, they found “if the user creates a Notepad file, the file is searched in the user’s HOME directory, in contradiction of
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
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)
Notepadto 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.
StartRunNoHOMEPATH policy controls the working directory when a program is run from the Start.Run dialog. Like it says in the KB article:
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
StartRunNoHOMEPATH policy do not apply.
Policies do what they are documented to do, not what you wish they did.