Error 1325.<username> is not a valid short file name

[guest]

My workplace has a reccuring problem with software installed from msi
packages. The apps work fine when logged on as an administrator, and for
anyone whose username *is* a valid short file name (less than 8 characters).

For other restricted users, starting the application sets off the Windows
installer for the package, and then this error appears:

Error 1325.<username> is not a valid short file name.

The application does not open.

Worse still, this can also happen when a user tries to open a different
application. That is, a user can open Application A and see the Windows
installer for Application B, followed by the error message. After clicking OK
Application A will start up.

Initially we blamed this on packages we created ourselves, but have since
found several commercial packages with msi installers that behave the same
way.

I have not been able to find reference to anyone else experiencing this
problem. Has anyone seen this before? found a solution?

Most of our users are students so their group policy is quite restrictive.
Might there be a setting in group policy that would cause this?

[guest]

We just resolved a very similar issue here. Here are the steps we took to
fix the problem.

1. Archive all email
2. Delete network account
3. Recreate network account
*from a new, blank account, do not copy from the old account
4. Check all permissions for that user on all network drives/shares they
have been granted access to
*be sure to remove the unknown SID from the old account
5. Delete all instances of the user’s local profile on any client machines
where that user has previously logged on
6. Log in as the user, and take ownership of all files inside their home
folder

[guest]

had this issue with activesync, the issue is not with the installer but more so permissions to the registry. You will need to look at the event log for the applications, then give yourself or the user admin rights temporarily. Visit the registry where the key was made and grant that user specific "read/write" acces to the key. This will clear the issue

[guest]

I had the same problem. The reason was roaming profile.



The value in registry for "User Shell Folders" (HKEY_CURRENT_USER/Microsoft/Windows/Explorer/User Shell Folders) was wrong.



For example wrong value for AppData was

\\myserver\home$\myLongUsername\AppData\Roaming



I replaced \\myserver\home$\myLongUsername with %USERPROFILE%. Eventually problem solved.



It may not me only reason that roaming profile is used if user profile path is hardcodedly written in this values, It may cause problem I think.

[guest]

What I did to fix this was to go to the User Shell Folders and change all of the %USERPROFILE%\AppData\Roaming\... to %USERPROFILE%\AppData\Local. Seemed to do the trick. Mass updates should be do-able using Group Policy.