PackageDeploy Application Packaging Forums - View Single Post - 1325 <username> not a valid short file name

08-30-2011, 01:00 PM

thanks dude, after hours you make me feel good.. !

> On Wednesday, August 15, 2007 9:00 PM J wrote:

> 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?
>
> Many thanks for any asssistance,
>
> Judy

>> On Tuesday, October 02, 2007 9:51 AM Danie wrote:

>> 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
>>
>> Hope this helps you.
>> Daniel

>>> On Tuesday, October 02, 2007 7:31 PM J wrote:

>>> Daniel,
>>>
>>> Thanks so much for taking the time to reply. Sadly this wouldn't be a
>>> solution here, as the problem occurs with most of our 1100 or so users (in a
>>> K-12 school). I have tested it with newly created accounts and it just
>>> depends on the length of the user name. We initially thought it was a
>>> permissions issue, but it just happened that we were testing with admin
>>> accounts that were valid short file names. An admin user with a longer name
>>> had the same problem.
>>>
>>> Thanks again, and glad you got it solved there

>>>
>>> Regards, Judy

>>>> On Wednesday, October 03, 2007 3:35 AM Dennis Bareis wrote:

>>>> Hi,
>>>>
>>>>
>>>> On Wed, 15 Aug 2007 18:00:01 -0700, JM <JM@discussions.microsoft.com> wrote:
>>>>
>>>>
>>>>
>>>> You haven't mentioned the version of Windows or Windows Installer but I'd also suspect the
>>>> msi and the fact that others also fail may just mean they have the same bug. Have you
>>>> had any msis install?
>>>>
>>>> I'd create a verbose log and have a closer look at what is going on:
>>>>
>>>> http://makemsi-manual.dennisbareis.com/logging.htm
>>>>
>>>> Bye,
>>>> Dennis
>>>>
>>>> P.S. A lot of our user names won't be valid as 8.3 and I have never seen this issue.
>>>> Dennis Bareis [Microsoft MVP] (dbareis@KillSpam.gmail.com)
>>>> http://dennisbareis.com/
>>>> Freeware Windows Installer creation tool (+ "ORCA automation"):
>>>> http://makemsi.dennisbareis.com/

>>>>> On Thursday, October 04, 2007 1:54 AM J wrote:

>>>>> Hi Dennis,
>>>>>
>>>>> Thanks so much for your feedback on this. I'll have a look at logging to see
>>>>> if I can find out more.
>>>>>
>>>>> We are running Windows XP SP2 with Windows installer 3.1.4000.1823 .
>>>>>
>>>>> The msi packages install OK, but when a user with a long user name runs the
>>>>> application, Windows installer starts up again and produces the error
>>>>> message. It's a long time since I tried making my own MSIs, because of this
>>>>> problem. I doubt I even have a copy of any of them now. What worries me now
>>>>> is that we can buy software that has an msi installer (e.g. AutoDesk CAD
>>>>> software and Paint Shop Pro 8) and the same error occurs.
>>>>>
>>>>> I have been thinking maybe it was something to do with our group policies
>>>>> but I haven't found anything that would explain it.
>>>>>
>>>>> Thanks again, JM

>>>>>> On Thursday, October 04, 2007 3:04 AM Dennis Bareis wrote:

>>>>>> Hi,
>>>>>>
>>>>>> On Wed, 3 Oct 2007 22:54:00 -0700, JM <JM@discussions.microsoft.com> wrote:
>>>>>>
>>>>>>
>>>>>> It sounds more like a bug in the msi to me now... :-)
>>>>>>
>>>>>> To log, you'd have to go the policy option. Look in the event log when it happens
>>>>>> for info on what was triggered and why (criptic but needed).
>>>>>>
>>>>>> As for the "error", you have to know what it is but my guess would be its not an error,
>>>>>> but you have created one by deleting the original source msi (its unavailable).
>>>>>>
>>>>>> Bye,
>>>>>> Dennis
>>>>>> Dennis Bareis [Microsoft MVP] (dbareis@KillSpam.gmail.com)
>>>>>> http://dennisbareis.com/
>>>>>> Freeware Windows Installer creation tool (+ "ORCA automation"):
>>>>>> http://makemsi.dennisbareis.com/

>>>>>>> On Tuesday, October 09, 2007 9:46 PM J wrote:

>>>>>>> "Dennis Bareis" wrote:
>>>>>>>
>>>>>>>
>>>>>>> Thanks, Dennis.
>>>>>>>
>>>>>>> I should have explained - I only deleted the MSIs I had created when they
>>>>>>> were no longer in use.
>>>>>>>
>>>>>>> The software we are having trouble with now was installed from an msi, but
>>>>>>> not one I made. The installer for these commercial products comes as an msi,
>>>>>>> and since the software gives the same error message as I got when I packaged
>>>>>>> msis myself, I thought that being installed from an msi was the common
>>>>>>> factor. The two products I can think of that get this error - Paint Shop Pro
>>>>>>> and Autodesk - are very different programs from different companies, and
>>>>>>> neither company can explain the error messages.
>>>>>>>
>>>>>>> Regards, JM

>>>>>>>> On Wednesday, October 10, 2007 5:04 AM Dennis Bareis wrote:

>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> If you send a verbose log (zipped please) of the error occuring I'll have a look at it.
>>>>>>>>
>>>>>>>> Bye,
>>>>>>>> Dennis
>>>>>>>>
>>>>>>>> On Tue, 9 Oct 2007 18:46:00 -0700, JM <JM@discussions.microsoft.com> wrote:
>>>>>>>>
>>>>>>>> Dennis Bareis [Microsoft MVP] (dbareis@KillSpam.gmail.com)
>>>>>>>> http://dennisbareis.com/
>>>>>>>> Freeware Windows Installer creation tool (+ "ORCA automation"):
>>>>>>>> http://makemsi.dennisbareis.com/

>>>>>>>>> On Tuesday, August 24, 2010 6:30 PM Ryisheed Wilson wrote:

>>>>>>>>> I 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

>>>>>>>>>> On Wednesday, October 27, 2010 10:15 AM Umit Coskun Aydinoglu wrote:

>>>>>>>>>> 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.

>>>>>>>>>>> On Wednesday, December 29, 2010 10:49 AM Scott Williamson wrote:

>>>>>>>>>>> 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.

08-30-2011, 01:00 PM	#3 (permalink)
Cagatay Ulubay Guest Posts: n/a	Re: 1325 <username> not a valid short file name thanks dude, after hours you make me feel good.. ! > On Wednesday, August 15, 2007 9:00 PM J wrote: > 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? > > Many thanks for any asssistance, > > Judy >> On Tuesday, October 02, 2007 9:51 AM Danie wrote: >> 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 >> >> Hope this helps you. >> Daniel >>> On Tuesday, October 02, 2007 7:31 PM J wrote: >>> Daniel, >>> >>> Thanks so much for taking the time to reply. Sadly this wouldn't be a >>> solution here, as the problem occurs with most of our 1100 or so users (in a >>> K-12 school). I have tested it with newly created accounts and it just >>> depends on the length of the user name. We initially thought it was a >>> permissions issue, but it just happened that we were testing with admin >>> accounts that were valid short file names. An admin user with a longer name >>> had the same problem. >>> >>> Thanks again, and glad you got it solved there >>> >>> Regards, Judy >>>> On Wednesday, October 03, 2007 3:35 AM Dennis Bareis wrote: >>>> Hi, >>>> >>>> >>>> On Wed, 15 Aug 2007 18:00:01 -0700, JM <JM@discussions.microsoft.com> wrote: >>>> >>>> >>>> >>>> You haven't mentioned the version of Windows or Windows Installer but I'd also suspect the >>>> msi and the fact that others also fail may just mean they have the same bug. Have you >>>> had any msis install? >>>> >>>> I'd create a verbose log and have a closer look at what is going on: >>>> >>>> http://makemsi-manual.dennisbareis.com/logging.htm >>>> >>>> Bye, >>>> Dennis >>>> >>>> P.S. A lot of our user names won't be valid as 8.3 and I have never seen this issue. >>>> Dennis Bareis [Microsoft MVP] (dbareis@KillSpam.gmail.com) >>>> http://dennisbareis.com/ >>>> Freeware Windows Installer creation tool (+ "ORCA automation"): >>>> http://makemsi.dennisbareis.com/ >>>>> On Thursday, October 04, 2007 1:54 AM J wrote: >>>>> Hi Dennis, >>>>> >>>>> Thanks so much for your feedback on this. I'll have a look at logging to see >>>>> if I can find out more. >>>>> >>>>> We are running Windows XP SP2 with Windows installer 3.1.4000.1823 . >>>>> >>>>> The msi packages install OK, but when a user with a long user name runs the >>>>> application, Windows installer starts up again and produces the error >>>>> message. It's a long time since I tried making my own MSIs, because of this >>>>> problem. I doubt I even have a copy of any of them now. What worries me now >>>>> is that we can buy software that has an msi installer (e.g. AutoDesk CAD >>>>> software and Paint Shop Pro 8) and the same error occurs. >>>>> >>>>> I have been thinking maybe it was something to do with our group policies >>>>> but I haven't found anything that would explain it. >>>>> >>>>> Thanks again, JM >>>>>> On Thursday, October 04, 2007 3:04 AM Dennis Bareis wrote: >>>>>> Hi, >>>>>> >>>>>> On Wed, 3 Oct 2007 22:54:00 -0700, JM <JM@discussions.microsoft.com> wrote: >>>>>> >>>>>> >>>>>> It sounds more like a bug in the msi to me now... :-) >>>>>> >>>>>> To log, you'd have to go the policy option. Look in the event log when it happens >>>>>> for info on what was triggered and why (criptic but needed). >>>>>> >>>>>> As for the "error", you have to know what it is but my guess would be its not an error, >>>>>> but you have created one by deleting the original source msi (its unavailable). >>>>>> >>>>>> Bye, >>>>>> Dennis >>>>>> Dennis Bareis [Microsoft MVP] (dbareis@KillSpam.gmail.com) >>>>>> http://dennisbareis.com/ >>>>>> Freeware Windows Installer creation tool (+ "ORCA automation"): >>>>>> http://makemsi.dennisbareis.com/ >>>>>>> On Tuesday, October 09, 2007 9:46 PM J wrote: >>>>>>> "Dennis Bareis" wrote: >>>>>>> >>>>>>> >>>>>>> Thanks, Dennis. >>>>>>> >>>>>>> I should have explained - I only deleted the MSIs I had created when they >>>>>>> were no longer in use. >>>>>>> >>>>>>> The software we are having trouble with now was installed from an msi, but >>>>>>> not one I made. The installer for these commercial products comes as an msi, >>>>>>> and since the software gives the same error message as I got when I packaged >>>>>>> msis myself, I thought that being installed from an msi was the common >>>>>>> factor. The two products I can think of that get this error - Paint Shop Pro >>>>>>> and Autodesk - are very different programs from different companies, and >>>>>>> neither company can explain the error messages. >>>>>>> >>>>>>> Regards, JM >>>>>>>> On Wednesday, October 10, 2007 5:04 AM Dennis Bareis wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> If you send a verbose log (zipped please) of the error occuring I'll have a look at it. >>>>>>>> >>>>>>>> Bye, >>>>>>>> Dennis >>>>>>>> >>>>>>>> On Tue, 9 Oct 2007 18:46:00 -0700, JM <JM@discussions.microsoft.com> wrote: >>>>>>>> >>>>>>>> Dennis Bareis [Microsoft MVP] (dbareis@KillSpam.gmail.com) >>>>>>>> http://dennisbareis.com/ >>>>>>>> Freeware Windows Installer creation tool (+ "ORCA automation"): >>>>>>>> http://makemsi.dennisbareis.com/ >>>>>>>>> On Tuesday, August 24, 2010 6:30 PM Ryisheed Wilson wrote: >>>>>>>>> I 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 >>>>>>>>>> On Wednesday, October 27, 2010 10:15 AM Umit Coskun Aydinoglu wrote: >>>>>>>>>> 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. >>>>>>>>>>> On Wednesday, December 29, 2010 10:49 AM Scott Williamson wrote: >>>>>>>>>>> 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.