Error: This installer needs access to "My Documents"

[jmccracken112]

The work around is to enable the local administrator account and do any installs using that account.

[ThiCop]

Actually this is also what solved the original issue.

The IT admin will have used his/hers IT Admin account to install the software.

[mkeur]

Thanks. This work around gets the software installed on the computer. But NI should fix this bug. It's a major pain to do this when you're deploying software to large user groups where computers have this perfectly acceptable Windows setup. Installers should not be choking on this.

[jmccracken112]

Agreed.

This is a huge pain in the a** because we have to give out the local administrator password to users who should not have that kind of access so they can get through installs (I mean even simple run time engines) without having to wait for IT to do it for them.

[ThiCop]

Hello mkeur and jmccracken,

I fully understand that this can cause alot of extra (and unwanted) work and at your side.

Unfortunately, I cannot help/fix this personally.

Would you like me to discuss these issues with some people from R&D and file a CAR (Corrective Action Request)?

[mkeur]

I would very much appreciate a fix to the installer over this issue. I have not found it to be an issue with any other installer other than NIs. The issue seems pretty simple: a network mapped documents folder (e.g. under S:\users\mk) is setup under Win7 as "My Documents" (S:\users\mk\My Documents). The NI installer fails looking for "S:\user\mk\Documents" and aborts. This naming convention seems to be a Windows 'auto/magical' process when one moves the documents location to network storage. An interesting side comment is the folder on the network device is "Documents" and is remapped by Windows 7 to "My Documents". It then will not let you find the path/location via the "Documents" folder name. As I said in an earlier post, this did not seem to be an issue under Vista, but occured after computers were upgraded to Win7. Thanks

[ThiCop]

Hello mkeur,

I want to verify one thing to make sure I'm not making any incorrect assumption.

The original poster used LabVIEW 8.6.1 to make the application in their installer (also defining the run-time engine that way).

Which version are you (both?) using?

I assumed the installers were made with the latest version, but I want to avoid making any wrong assumptions.

[mkeur]

The version I'm using is CVI 2010.

[ThiCop]

Thanks for the feedback!

It seems that I do find some reports about this issue in our internal database about this specific Run-Time Installer.

It seems to be a Windows InstallShield issue (which is used in the Run-Time Engine installer).

However, I don't seem to find other reports about it in later versions.

This leads me to believe that this issue is resolved in the later Run-Time Engine Installers.

I would like to verify if this issues still occurs in the latest Run-Time Engine.

However, I currently don't have a set-up at my disposal that uses a network mapped "My Documents" folder.

Can anyone verify that they see the same behavior with the latest CVI Run-Time Engine Installer?

(http://joule.ni.com/nidu/cds/view/p/id/4105/lang/en)

[FranzS]

Hallo Thierry,

I think I have mainly the same problem.

I build an installer on a W7 64bit computer with LV2012SP1f5 32bit.

The installation on a W7 64bit engine runs without any problem.

The installation on a XP 32bit engine shows the same error message as described above:

Error: The installer needs access to “My Documents”. However, this location “U:\Eigene Dateien\” is not available. Ensure that this directory exists and is available and run the installer again.

On the XP computer I started the setup.exe with “Run as…” and my Admin logon profile.

If I start the XP engine with my Admin profile the failure was not shown!

Kind Regard,

Franz Sturm

CLD