We help IT Professionals succeed at work.

We've partnered with Certified Experts, Carl Webster and Richard Faulkner, to bring you two Citrix podcasts. Learn about 2020 trends and get answers to your biggest Citrix questions!Listen Now


Roaming ini Files

jmj050997 asked
Medium Priority
Last Modified: 2013-12-28
I'm still trying to setup NT workstations connected to netware servers. I have about 1000 workstations and all users are roaming: they can log on any workstation and get their environment (roaming profile) and applications. I have extensively used System Policy Editor to set the UserShellFolders to server based directories.

Now I have a problem with 32-bit applications whose programmers didn't understand that WriteProfileString is an OBSOLETE function, and with most of 16-bit applications that use INI files.

All these INI files are by default located in the %WINDIR% directory (C:\WINNT) and excepted a few applications that can be configured to look for their ini files in a user directory, this behaviour breaks the roaming  system cuz INI files are not USER-BASED but SYSTEM-BASED.

What I need is a way to make all programs write and read their ini files in a J:\NT subdirectory that is private to each user.

* A first solution is to copy these files during the LOGON script to C:\WINNT .... but I didn't find any LOGOUT script to copy the files back to J:\NT

* A second solution is to use the HKLM\SOFTWARE\Microsoft\Windows NT\IniFileMapping subkey which works very well to map ini files to registry entries. Anyway, I didn't find any DEFAULT MAPPING so this implies adding one subkey to 1000 workstations each time a new application that writes to ini files is installed...

* A third solution would be to change the %windir% environment variable to J:\NT.... this didn't work !

* Also tried to add J:\NT to the PATH... no success...

Now it's up to you: How do you deal with these F*****G ini files ? ANY IDEA HIGHLY APRECIATED !

I again thank Microsoft for doing half of the work... they permit roaming users, they have a user shell folder called Application Data.... and they do not modify their own API to write to this folder instead of SYSTEMROOT. *GRIN*

Watch Question

I have (had) the same problem and will provide an answer now.

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts

* right, there is no logout script. I did it by defining my own logout script and include this into the start menue. Since you can not disable the main logout function this is not secure. With this there is another problem: If you logout the batch will copy the INI's before the programs are closed. Since the programs save their INI on exit, you always copy old information. So I included  in my batch that the programms get closed. This only works if there are no unsaved data. -> the solution is not nice.

* Ini filemapping is supposed to make the default on its own. You provide the default INI in \winnt , at first time the information is read and automatically copied to the registry.
I didn't test it, but someone (you?) reports that it did not work. In this case you can prepare the appropriate default settings and apply it during the login script.

* more than one function relys on %windir% !

* Path? of course not

You didn't mentioned .LNK files (they don't work), but there is the possibility to do hard links in NT like in Unix. A hard link can not be distinguished from a file, so it would work (once). The problem is that most programms does not change the file, they write a temp file and then delete the original (the link) and rename the temp file. Maybe you have luck with some INI's

I wonder that you do not use programms like SMS or NetInstall, they claim to handle all this.

However I think INIFILEMAPPING is best. Up to now I didn't find the time to test this.

Have a look in:

Your problem may be solved with:
I didn't test, but from the readme, it is what you are searching for.


Homepage of ini2reg is:  http://www.funduc.com/otsoft.htm

But I think it only copies INI files into the registry.

Inifilemapping is designed to solve the problem, somehow it must work. On the MS server there is somewhere a more detailed description of the inifilemapping system:


More info I have:

You should first try to convince the programm to store its INI-File in the users homedirectory. For some programms there is a
                  seperate CFG File which tells where to store the INI, other have all this in the registry.
                  If this is not possible use the INI-File Mapping System which is build in NT. With this you can do all you want (in theory).
                  You can supply a default INI file which contents will be copied to the registry at first login.
                  Nevertheless you must setuop all this by hand using regedt32 for every program. It is not too difficult, but I think there is no
                  util which will do it automatically for you.
If a Windows-based application tries to write to WIN.INI, SYSTEM.INI, or any other section listed in the IniFileMapping key,
                  and if the application uses the Windows NT Registry APIs, the information is stored in the Registry. If the application writes
                  to other sections of the .INI file or tries to open the .INI file directly without using the Windows NT Registry APIs, the
                  information is saved in an .INI file.

                  To find mapping information in the HKEY_LOCAL_MACHINE\Software key, the system looks up the filename.ext of the
                  initialization file. If a match is found, it looks under the mapped key for the specific application name and a variable name, and
                  if necessary it continues to look for keys whose value entries are the variable names. If no mapping for either the application
                  name or filename is found, the system looks for an .INI file to read and write its contents.

                  In the entries in the IniFileMapping key, the following symbols are used:

                  ! Forces all writes to got to both the Registry and to the .INI file on disk.
                  # Causes the Registry value to be set to the value in the Windows 3.1 .INI file whenever a new user logs in for the first time
                  after Setup, if Windows NT was installed on a computer that had Windows 3.1 already installed.
                  @ Prevents any reads from going to the .INI file on disk if the requested data is not found in the Registry.
                  USR Stands for HKEY_CURRENT_USER, and the text after the prefix is relative to that key.

                  SYS Stands for HKEY_LOCAL_MACHINE\SOFTWARE, and the text after the prefix is relative to that key.


I don't have the time to test this right now cuz I must leave (I'll check all this tomorrow...)

Anyway, the problem I have with IniFileMapping is that I didn't find any entry that says:

- If any program wants to write/read to any ini file (lets say aaa.ini), map this to HKCU\Software\aaa.ini\....

--> I just want to add a DEFAULT IniMapping at the end so that I'm not obliged to update my 1000 Workstations each time a new program writes to a new ini file.


Please read the info I supplied.
It states that you "only" have to supply the default INI to every workstation. (Maybe you can use the "replicate" feature).
As I said, if it not work create a .REG file with the settings and let the user add this at login

I found another text file with only a little bit more information:

PSS ID Number: Q102889
Article last modified on 06-23-1995
3.10 3.50

Under Windows NT, .INI file variables are mapped into the Registry as
defined in the
mapping key. The Win32 Profile application programming interface (API)
functions look for a mapping by looking up the filename extension portion
of the profile file. If a match is found, then the search continues under
that node for the specified application name. If a match is found, then the
search continues for the variable name. If the variable name is not found,
the value of the (NULL) variable name is a string that points to a node in
the Registry, whose value keys are the variable names. If a specific
mapping is found for the variable name, then its value points to the
Registry value that contains the variable value.
The Profile API calls go to the Windows server to look for an actual .INI
file, and read and write its contents, only if no mapping for either the
application name or filename is found. If there is a mapping for the
filename but not the application name, and there is a (NULL) application
name, the value of the (NULL) variable will be used as the location in the
Registry of the variable, after appending the application name to it.
In the string that points to a Registry node, there are several
prefixes that change the behavior of the .INI file mapping:
   ! - This character forces all writes to go both to the Registry and
       to the .INI file on disk.
   # - This character causes the Registry value to be set to the value
       in the Windows 3.1 .INI file when a new user logs in for the
       first time after setup.
   @ - This character prevents any reads from going to the .INI file
       on disk if the requested data is not found in the Registry.
   USR: - This prefix stands for HKEY_CURRENT_USER, and the text after
          the prefix is relative to that key.
   SYS: - This prefix stands for HKEY_LOCAL_MACHINE\Software, and the
          text after the prefix is relative to that key.


* I had a look at http://www.tek.com/VND/Support/Release_Notes/RegMap.html This seems interesting but this is a part of Cytrix WinDD documentation... and I cannot buy windd.

* ini2reg only moves ini files to the registry, but doesn't make an old program read and write to the registry. For this, I must then update the IniFileMapping/XXX.INI for all my 1000 workstations.

--> I still don't see how a new program that writes to a new .INI is going to write/read to the registry, without adding a new entry to the IniFileMapping subkey.


--> I still don't see how a new program that writes to a new .INI is going to write/read to the registry, without adding a new entry to the IniFileMapping subkey.

Now I understand you!
You are right this is not possible, you have to make this entry on every WS.
How do you handle other problems where you have to change HKLM of all WS?
I have two solutions for this:

- remote registry editing. I think there is a tool that can do this in a batch file. However, you need to maintain a list of all the names of your WS.

- Autostart.nt is provided with the server resourcekit. You can use it to process a script at boot time. This script would be similar to a user-login script, but can change HKLM settings. Place the script and all additional files you need (like .REG) on a server volume. At boot you can check in the script if there is a key already set, and if not execute the .REG file with regedit.

If you want to use the second solution you may need some more hints on autoexec.nt


I coded a small KiXtart script that is called during the logon script, that launches as supervisor (using su.exe) every batch on a server that have never been launched on a workstation.

All batches in Z:\DEPLOIE\ONCE are numbered, and the number of the next batch to run is saved in the registry HKLM.

$Dep = ReadValue( "HKEY_LOCAL_MACHINE\SOFTWARE\SGSI\Deploie", "Dep" )
    $ret = AddKey( "HKEY_LOCAL_MACHINE\SOFTWARE\SGSI\Deploie" );
    $Dep = 1

$BatchDep = "Z:\DEPLOIE\ONCE\D" + $Dep + ".BAT"
WHILE EXIST( $BatchDep )
    ? "Processing: " + $BatchDep
    SHELL "CMD /C echo ADMINPASSWORD|su -l -e ADMINPASSWORD " +chr(34)+ "cmd /c $BatchDep C:\SGSIPARM" +chr(34)+ " DOMAIN > NUL"
    $Dep = Val("$Dep") + 1
    $BatchDep = "Z:\DEPLOIE\ONCE\D" + $Dep + ".BAT"

$ret = WriteValue( "HKEY_LOCAL_MACHINE\SOFTWARE\SGSI\Deploie", "Dep", "$Dep", REG_SZ )

This way, I can make modifications to all workstations. When I include these modifications in the BASE WORKSTATION INSTALLATION,  I change the original Dep value in the registry of these new workstations, so that old batches are not processed.


I have been trying to install IniFileMapping for Office 4.2.

There are no problem at all with Word 6.0 and Excel 5. Access 2.0 needs an empty msacc20.ini in C:\WINNT for the mapping to work, but I have a problem with powerpoint 4.0:

Although I have the right IniFileMapping set in HKLM for powerpnt.ini, Powerpoint doesn't work ! --> Microsoft do not use the profile API (ReadPrivateProfileString) in their own program... they must be loading the file as a text file !



I see a danger in your script: Every user can read the script and look up the AdminPassword !?

For Powerpoint I do not know. You can try the hardlink (Think from Posix) method.

I am out of hints.


Yes, this is a danger i'm aware of. Although I don't use a real administrator but a user that has special rights on the local workstation (not domain wide), i'm gonna write a program that does the same but in a non-readable format ...

I should email KiXtart'coder for a new feature: non-readable scripts ! *laugh*


Since I can not help you further, you should evaluate the answer now (or ask something I might still know).
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.