We are trying to deploy MiKTeX 2.9 to a number of managed Windows 7 (64-bit,
if it matters) workstations. After installing, users get an "invalid control
sequence" error when running any MiKTeX programs as themselves.
The installation is done as an Administrator user. I tried to run
C:\Program Files (x86)\MiKTeX 2.9\miktex\bini\initexmf.exe --dump=<pkg>
where <pkg> is etex, latex, pdfetex, pdflatex, pdftex and tex to generate
I did find the MiKTeX installer wants to install the texmf tree in
C:\ProgramData\MiKTeX\2.9, and non-priviledged users are not allowed to write
to that directory. In an attempt to get around this, I tried installing with
the common-data and common-config directories moved to C:\MiKTeX\2.9 At least
users are able to write generated package and format files to this directory
I haven't found any solution for getting around the "invalid control sequence"
Any suggestions from the gurus here?
I don't understand why you didn't let miktex use the default locations. In
multiuser mode the restricted user would have get local trees (UserConfig and
UserData) in their user profiles for packages installations and format files.
There is no need for them to be able to write in the main installation tree or
in CommonData and CommonConfig.
I never saw an "invalid control sequence" error and I have a lot of doubts
that you actually quoted the error message correctly. You certainly didn't
give informations about it (e.g. which application actually issue the error
I have tried installing with the standard and custom common-data and common-
config paths in an effort to narrow down whether the problem was in accessing
those file directories.
The issue I have is when I run "latex" or "latex.exe", the error reported on
the screen is "latex.exe: Invalid control sequence.", then the program quits.
I can run "latex <filename>" and get the exact same error.
The exact same error is returned (except for the program name at the beginning
of the error) for tex.exe, pdftex.exe, pdflatex.exe and etex.exe.
This error does not occur for the administrator user, but it does occur non-
administrator users on the system (mentioned in my first post). The
installation was done for "all users" when initially installed; a complete
MiKTeX installation was selected at install time.
Error being reported is coming from Libraries/MiKTeX/Core/config.cpp line
Progress: turns out the problem has to do with users that use roaming profiles
where %localappdata% is removed at logout. MiKTeX does not handle this
situation very well.
To get MiKTeX working and avoid the above "Invalid control sequence" error
mentioned above, the user can run MiKTeX 2.9 -> Maintenance -> Settings and
"Refresh FNDB". This rebuilds .fndb files in
The problem comes in when machine policy settings call for any profile data on
the local disk to be removed at logout (after any roaming profile data is
sync'ed to the fileserver). All data in %localappdata% is lost.
Is there a way to rebuild the .fndb files in %localappdata% at the command
line, rather than using the GUI mo.exe program? Or is there a registry key
that can be set to direct MiKTeX to use an alternate location to store such
data, such as %appdata% (roaming profile application data that is sync'ed at
You can update the fndb on the command line with initexmf -u, see
documentation of miktex. If the users have local font maps or use xetex they
perhaps also should call updmap or fc-cache. You could also regenerate the
formats (but normally miktex regenerates them on the fly when they are
You can at installation time change the location of the UserData root and e.g.
put it in the roaming profile. But you should be aware that the root can get
quite large over time (mine is about 400 MB but most of it is from the font
cache of luatex) and so can slow down the logout. At a discussion last july in
the mailing list a user at the end put it in C:\temp.
We do have folder redirection in place for our users' roaming profile AppData
directory, so the fact that the UserData directory tree can grow quite large
is not an issue in our environment.
I tried installing with --user-data=%appdata%\MiKTeX\2.9; unfortunately this
expands %appdata% at the time of the installation, not when the user runs
MiKTeX programs. All users then try to use the administrator account's
%appdata% directory as their UserData tree. This clearly will not work.
After searching through the registry, I found key
HKLM\SOFTWARE\Wow6432Node\MiKTeX.org\MiKTeX\2.9\Core has string value UserData
set to the location of the UserData tree. It would be a simple fix to just
change this registry key value to "%appdata%\MiKTeX\2.9". Unfortunately, the
MiKTeX Options (mo.exe) binary claims this is an "invalid argument".
Other values for this registry key value that do not work:
%appdata%\MiKTeX\2.9 Invalid argument
"%appdata%\MiKTeX\2.9 Invalid argument
\%appdata%\MiKTeX\2.9 Generates UserData tree in \%appdata%\MiKTeX\2.9, where
"%appdata%" is not expanded
I can set this key to "L:\AppData\Roaming\MiKTeX\2.9" to get the desired
behavior (where L: is mapped to each user's home directory, and roaming
profile application data is redirected to the fileserver where L:\AppData maps
Is MiKTeX not able to use shell environment variables in file locations? Or is
there some way to escape them? I see no such reference in the MiKTeX 2.9
Hm. I never had to do a multiuser install. But imho is should be possible to
use variables with the --user-data or the switch would be rather useless.
Perhaps you should make a bug report that "--user-data=%appdata%\MiKTeX\2.9;"
didn't work as expected. Then Christian could tell you if or how it should
Thank you for your assistance with this issue.
Turns out I ran across one more issue (for which I have a work-around, but
wanted to post it here in case other users have trouble with it). After
installing MiKTeX 2.9 with the --user-data option set as documented above,
texify will not run for mortal users. latex/pdflatex/etc. all work fine.
It appears %appdata% is expanded during the installation process, the the
UserInstall or UserConfig directory is inserted into one (or more) of the
configuration files texify uses. As a result, when texify is run, it always
searches the %appdata%\MiKTeX\2.9 directory for the local administrator user,
not for the user running texify. Anyone installing a private copy of MiKTex
(not for all users on the computer) would not run into this problem, as
%appdata%\MiKTeX\<versioin> will resolve to the same location at run-time and
The workaround in my case is to specify the --user-config and --user-install
options, using the same path as specified in the --user-data option.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.