Associate different vi search paths according project

HI
i Would like to know if it is possible to associate the option VI search Paths with the project
like this you can have different vi search paths for each project you handle
I have read that it can be possible with labview.ini but I have not seen how to do that
Thanks for your help

I believe this is what you are looking for:
How Can I Change or Set the VI Search Path for LabVIEW Executables?
If not, post back with some additional details on what exactly you want to achieve.
Adnan Zafar
Certified LabVIEW Architect
Coleman Technologies

Similar Messages

How to define Containing Project Directory in the TestStand Search Path?

In TestStand Search Path one of the list is "Containing Project Directory". How can I define this?

Legal Engineer -
TestStand does expose the "containing project directory" in the search directories dialog box. It only has meaning for the FindFile API function when the "currentSequenceFile" parameter is set to a project file. I agree that it is confusing in that it does not apply to steps finding code modules. If you unchecks this setting and you reload a workspace, any projects that use relative paths to specify their files may no longer find their files.
In general the suggestion is to leave it checked and ignore it.
Scott Richardson (NI)
Scott Richardson
National Instruments

VI Search Path not working in LV2011 for VI Server Plug-ins with exe

I have found what seems to be a problem with the search path when a LabVIEW 2011 built executable calls a Plug-in VI.
When the plug-in VI has subVI’s from vi.lib on its diagram the executable has to know where to find them. Not all VI’s in vi.lib are part of the run time engine or the dll’s that may get generated as part of the build. The things you have to do to make plug-ins work for an executable are explained in several Developer Zone articles. The article titled “How Can I Change or Set the VI Search Path for LabVIEW Executables” describes the ini file setting viSearchPath. When this is set to the vi.lib directory I have not encountered problems with previous versions up to and including LabVIEW 2010.
I have come across an example in LabVIEW 2011 where it doesn’t work. I have attached an example (I am using LV2011 SP1). It demonstrates the basic plug-in architecture. Everything works in the development environment. But it doesn’t work from a built exe. I haven’t included the actual built exe in the zip file in case that causes a problem downloading it. If you run the build spec from the src directory project file the exe should get generated in the bld directory. The problem appears to occur when certain VIs from the analysis library are in the Plug-in. In the example attached, the Plug-in VI is very simple but I have placed the troublesome SubVI on the diagram. The VI in this example where there is a problem finding it is the Butterworth Filter VI. I have placed it on the diagram in a conditional disable structure so it is easy to enable and disable. When enabled and you run the test Plug-in VI the error 1003 is raised, meaning a subVI cannot be found in the dynamically called VI (for example see this post). Note that a way round this may be to incorporate the Plug-in VI into the built exe but this shouldn't be necessary. It’s not a problem with this specific filter VI, as it occurs for other VIs I try on the diagram. However if you place an FFT VI on the diagram there is no problem. I suspect that one is built into the Run-Time Engine.
I also note I am running Win7 64 bit and 32 bit LabVIEW (note the relevant viSearchPath in the ini file – you may need to change if you are on different version of Windows). If the example is converted to LabVIEW 2010 everything works as expected for the built exe. I tried that on a colleague’s computer running XP and 2010 but I am pretty sure in still also works on Win 7.
Things I am suspicious of are that the analysis VI’s are part of a LabVIEW library (lvlib) and perhaps something has changed there? I understand there is a problem with OOP in LabVIEW 2011. Perhaps it is related to that as that seems to be an issue in 2011 (see this Discussion Forum post). Perhaps it is related to OS version?
I also tried generating a Source Distribution to extract out all the vi.lib VI’s and place them directly in the Plug-in directory. That didn’t help.
Interested in whether anyone else reproduces this behaviour. In any case something is different in 2011.
Attachments:
LV 2011 test Plug-in.zip ‏42 KB

I found some more out about this issue working with my local NI rep here in Australia. Apparently something has changed in the compiler between LabVIEW 2010 and 2011. Using the viSearchPath token in the ini file, as described in various Developer Zone articles, now guarantees that the Plug-in will not work. The only way to make it work appears to be to create a Source Distribution. I noted in my original post that I had already tried this and it would not work. It turns out that having the viSearchPath token in the ini file when using a Source Distribution causes the error 1003 to occur. When the token is taken out of the ini file the Plug-in (containing an analysis VI) with a Source Distribution works - in the simple example I posted.
Well I then found its a bit more complicated than this. It all worked for the simple example I posted. Recall we found the error when there was an analysis VI in the Plug-in VI. In our actual application (which is a large one) that calls Plug-ins - we still got the error 1003. By trial and error I found a workaround. There are certain Build Spec settings for the calling exe that I set and found worked. On the Additional Exclusions page I found that I had to make sure that I left unchecked "Modify Project Library File after removing unused members". I've always had trouble understanding the need for this setting. In the Build Spec Help on that page it notes that the build will take longer. In most builds you remove polymorphic VI instances, remove unused members of Project libraries and also Modify the project library file after removing the instances (this is a sub setting of the previous). This makes the exe smaller in size and a quicker build time. Obviously modifying the project library caused a problem. In the big application exe calling Plug-in, I probably have the same analysis VI on the diagram (I haven't actually checked and also whether it is the same polymorphic instance) and in the simple example I posted I definitely did not have VI in the calling exe example - so there may be some clue there. I should try putting the same analysis VI on the calling exe diagram in the simple example to see what happens but I'm running out of energy on this one :-(
So none of this gives me much confidence and I wish I could get a better explanation from NI regarding this behaviour to be sure I am not going to encounter a different problem for different calling exe and Plug-ins. I was advised that a CAR would be issued. Perhaps this is now expected behaviour for 2011 but it would helpful if some definitive explanation could be given about what has changed from LV2010. And an update of Developer Zone articles on the subject would be helpful.

Vi search path

Hello all,
I have a problem with "vi search path" in Labview.
First, here are information about our directories architecture to understand the problem.
We are using the following architecture for our developments:
Each project is located in a specific directory.
ex: Project 1 is located in D:\Data\PRJ1
Project 2 is located in D:\Data\PRJ2
In the project directory, there is a subdirectory called "TestTools".
All Labview developments for a given project are located in this directory
and its subdirectories.
ex: D:\Data\PRJ1\TestTools
In the TestTools directory, there are subdirectories:
--> ...\TestTools\Tests : containing test VIs (top level)
ex: D:\Data\PRJ1\TestTools\Tests\Test1.vi
D:\Data\PRJ2\TestTools\Tests\Test45.vi
--> ...\TestTools\Utils : containing sub-vi for the tests.
ex: D:\Data\PRJ1\TestTools\Utils\HF\HF_cfg.vi
D:\Data\PRJ2\TestTools\Utils\CAN\CAN_start.vi
If I add "[topvi]/*" in the "vi search path" menu, Labview will search
the sub-VIs for my application in the directory of the toplevel VI (and its sub-directories).
ex: if I open "D:\Data\PRJ1\TestTools\Tests\Test1.vi", Labview will search the sub-VIs
in the following directory: "D:\Data\PRJ1\TestTools\Tests".
Labview will not be able to find the sub-VI called "HF_cfg.vi" which is
located in "D:\Data\PRJ1\TestTools\Utils".
I can add "D:\Data\PRJ1\*" in the "vi search path" menu but It will work only for Project 1,
and it will not work for Project 2.
I must replace it by "D:\Data\PRJ2\*" to work with Project 2.
If I don't do that, Labview will not find sub-VIs for the tests of Project 2.
(or it will find wrong sub-VIs located in the directory of Project 1 !!)
This is a problem because we often switch from one project to another.
We close and re-open Labview when we switch from one project to the other to be sure
that Labview is not using VIs already loaded in memory, but we still have problems
with "VI search path".
Is there a way to configure Labview to search sub-VIs from an upper directory
that the topvi directory?
Something like that: "[Topvi]\..\*"
(the parent directory of the topvi directory, and all its sub-directories).
I tried "[Topvi]\..\*" but Labview does not support this type of directory.
Someone suggested me to use "Source code control".
I am using Labview Full Dev (not Labview Professional) so I can't use "Source Code Control".
Is there another solution for my problem?
Thanks for your support.
NLu

Dear NLU,
the behaviour is somehow strange. I have projects with some similar folder layout in which sub-VIs are located under ..\..\DMS\sub.vi relative path from the toplevel VI. The search path is set to default. These VIs are really sub VIs not dynamically loaded. The toplevel VI holds the relative path to its sub VIs if they are on the the same drive and the absolut path if the drive is different. This is a least true from LV 3.0.1 to LV 7.1 under all Windows OS I have used (95 and ME I haven't used).
Unloading LabVIEW when changing the project is absolutly neccessary since LV holds a list of all folders where it have found VIs during a session. If you switch from PROJ1 to PROJ2 LV will load VIs with the same name in PROJ1 and PROJ2 but with different paths from the path used during working with PROJ1. Unfotunatly there is no menu entry for "Empty VI found list".
The solution provided by Evan can be made simplier. Create a shortcut to LabVIEW and use the command line parameter -pref to load the desired preference file. Look in the help under "LabVIEW-Defined Command-Line Arguments" for the exact usage.
Waldemar
Waldemar
Using 7.1.1, 8.5.1, 8.6.1, 2009 on XP and RT
Don't forget to give Kudos to good answers and/or questions

Lldb equivalent of gdb "directory" command for specifying source search path?

Looking for the lldb equivalent of the gdb "directory" command to add search paths for finding missing source code files (due to moved directories). Or possibly similar functionality within xcode...
Thanks in advance!

Great, thanks for the pointer although according to the lldb console the "add" command needs a "substitution pair" argument and the "Insert" command needs a new "image search path" and the "target modules list" command only gives a list of dylib modules. I played around a bit and the construction resembles more of a dylib module search path .i.e it looks like you only can revert the module search path but not separate it from the source path.
It would be nice to find out more details about different search-path capabilities within lldb. You don't happen to know where to find more thorough LLDB manuals or other useful documentation besides the "LLDB to GDB Command Map" (http://lldb.llvm.org/lldb-gdb.html) and the "LLDB Tutorial" (lldb.llvm.org/tutorial.html), do you? Also, any idea where to find the official doc pages for lldb. Unfortunately "http://lldb.llvm.org/docs.html" is still empty and I didn't find anything useful in the llvm github.

[Embed] search path

Hi, I have a few embedded assets:
[Embed(source="button.png")] private var btnImg:Class;
var b:Bitmap = new btnImg() as Bitmap;
However, I can't seem to add something to the search path
that the Embed tag uses to locate resources.
There's the additional problem that my .as file is referenced
from another file, e.g:
project1\MyButton.as -- has the embed tag
project2\client.as -- has a MyButton() control
project2\skin\* -- is where Embed[] should look for assets,
including those found in MyButton.as
this is my command line:
%SDKPATH%\bin\mxmlc.exe %SRCFILE%
-compiler.source-path=%COMMON_CLASSES%
Where SDKPATH is where the flex-2.0.1 SDK is, SRCFILE is the
full path to 'client.as' and COMMON_CLASSES refers to the
'project1' directory. Ideally, I should be able to add another
parameter:
-compiler.embed-path=c:\project2\skin
and have the MyButton inside client.as read its resources
from there...

Yes, but the problem is that the relative path is relative to
the source file...
1) common_classes/CoolButton.as [uses img/cool1.png]
2) project1/TwoButtons.as [uses img/background.png]
When I try to compile TwoButtons, the compiler is looking for
"common_classes/img/cool1.png" and "project1/img/background.png".
However, I want the CoolButton class to be fully generic, and
thus use skins from inside the project folder, i.e.
"project1/img/cool1.png".
There _has_ to be a way to change the embed search path. I
don't want to maintain N different copies of my common classes just
because they use N different embedded assets.

TestStand 4.1.1 vi search path

    This is so low-level I'm almost embarassed to ask. I'm using TestStand 4.1.1 over LabView 8.6, both of which are licensed as full development systems.
In order for our organization to make better use of (non-NI or Labview) source control, we've created a common directory structure for several developers over several large TestStand/LabView projects. This includes areas for "common VIs" that are reused across projects. So I'm in the process of migrating a rather complex project into a new directory structure. The sequences and VIs in question were working perfectly under TestStand 4.0/LabView 8.5 prior to this attempted migration.
   My test sequences (and sub-sequences) can't seem to find needed VIs, even though they exist in directories that are included in the search paths I configured. (An annoying sub-problem is that TestStand appears to "hang" while the LabView interface underneath the TestStand window is prompting for a VI's location. I have to click the LabView item in the Windows menu bar to get LabView "on top" and see what the problem is.)
   I've already added several paths to both the LabView and TestStand VI search paths, and I've even checked the "search subdirectories" box, but the items are not being found. It's going to take weeks to lead TestStand and LabView by the nose to find all this stuff.
   I can't believe this would really be a bug. I tried searching the forums for an answer and had no luck. I can't be the first one with such a problem, so help me out with some search terms so I don't have to clutter the forum with such basic stuff. Thanks.
-M

trosier, Neurotika,
It appears as if LabVIEW is having trouble finding your VIs, not TestStand. When TestStand loads the VI you have designated as a code module into memory, if you have the LabVIEW development environment designated in the LabVIEW adapter settings, we tell LabVIEW to load the VI via its ActiveX interface.
If TestStand is unable to find the top-level VI, you will see a dialog like this:
If LabVIEW is unable to find a sub-VI, you will see a dialog like this:
Notice that the TestStand dialog has an additional checkbox at the bottom that allows you to select an absolute path. Also notice that TestStand specifies what file its looking for in the Files of Type box while LabVIEW allows you to choose All LabVIEW Files. Which dialog are you seeing?
Another way to test this is to try to open one of your VIs from disk (by double-clicking on it). If you get a Searching for SubVIs dialog, then it is LabVIEW that can not find the dependencies.
Or if you open the specify module pane of the sequence editor, if TestStand cannot find the top-level VI, you will see a file not found warning like this:
If TestStand can find the file, but LabVIEW cannot find a sub-VI, then you will not get a warning or error until the VI is loaded.
The reason that this matters is that TestStand and LabVIEW do not share their search directory lists. If you have moved files, you will need to know which application cannot find its files.
Message Edited by Josh W. on 04-23-2009 11:27 AM
Josh W.
Certified TestStand Architect
Formerly blue
Attachments:
subVI not found by LabVIEW.JPG ‏31 KB
TestStand file not found.JPG ‏7 KB
VI not found by TestStand.JPG ‏31 KB

Cycle was detected in the build path of project

Hi
I was trying to create a Test application for MDB.
Here from the webContent I call the service locator in the EJB folder and get the bean object. Using the object I need to put a message in the MQ.
The onMessage method<present under EJB folder> picks up the message<which is a key> and then it has to refer the value in the Map which is under the ../WebContent/Javasource/..
But when I try to complile the project it is giving a error stating that A cycle was detected in the build path of project: MDBTestEJB.
How do I solve this ?? Please help ?

The fix for this - regardless of IDE - is to use a
bit of common sense, and good old-fashioned logic
(remember that?). You've obviously got (at least) 2
things that are dependent on each other, which - if
you remember the Chicken and Egg problem* - can't
possibly work. Work it out for yourself, you're
writing software, after all. If A needs B to do some
work but can't because B needs A first, you've got
problems
* sensible "it was the egg. Something
not-quite-like-a-chicken-but-close mated with
something-else-not-quite-like-a-chicken, and produced
an egg that eventually hatched into a chicken"
notwithstandingOK georgemc, I allowed you to motivate me to look for a better fix. I think I came up with a solution but I'd like to see if you, or anyone else, agrees with it.
First let me say that I'm using a persistence layer, which I've never done before, and with cardinality annotations different classes need to reference each other cyclically.
My problem was that I had class A in project 1 that depended on class B in project 2, but class B (project 2) also depended on class A (project 1). This meant that I had project 2 on the project 1 build path and vice versa; which is why I was getting the error.
After your post I started to think about it and it seems that my original solution didn't do a very good job of utilizing the extensibility that Java's OO gives us. My new solution is to remove any reference of class A that is in class B and also remove project 1 from the project 2 build path. Then extend class B into class ChildOf_B in project 1 and insert the references to class A in the new child class. I of course keep project 2 on the project 1 build path.
I've since told eclipse to throw an error for build path cycles instead of a warning and I no longer have any problems.

[Help] LabVIEW Search Paths Questions...

Is the "Tools" \ "Options" \ "Paths" \ "Search Paths" stored on the PC that is running LabVIEW or stored in the currently opened VI?
Also can I specify relative search paths for example: "<topvi>\..\..\..\Library\MyLib\*"
Is the search recursive? i.e. If there are subfolders, with subfolders will it drill down looking for the missing VI's?
The issue I have is that I have a project in a directory structure defined by a configuration control program i.e:
Y:\Test Equp\Project\Modules\Library\MyLib\* (there may be one or more sub folders contain VI's).
Y:\Test Equp\Project\Modules\MyApplication\* (there may be one or more sub folders contain VI's).
On the target the structure might be:
C:\Final\Library\MyLib\*
C:\Final\MyApplication\*
The issue is when I copy the files from Y: on my PC to C: on the PXI rack and open the top level VI in "MyApplication", LabVIEW cannot see the files in the "MyLib" until I tell where one VI is in each sub folder in "MyLib". This is a pain, specially if I make changes and transfer the file back to my PC as I have too go through the process again!
If I can spec a search path for the library files then it should just find them on either my PC or the PXI rack...
Thanks
Christopher Povey
Senior Test Systems Engineer for BAE Systems.
Solved!
Go to Solution.

ChristopherPovey wrote:
Is the "Tools" \ "Options" \ "Paths" \ "Search Paths" stored on the PC that is running LabVIEW or stored in the currently opened VI?
It is specific to that PC. It is stored in the labview.ini file.
Also can I specify relative search paths for example: "<topvi>\..\..\..\Library\MyLib\*"
You can, but that's not really the solution to your problem.
Is the search recursive? i.e. If there are subfolders, with subfolders will it drill down looking for the missing VI's?
That's what the asterisk at the end signifies. From the LabVIEW Help:
After you select the directory, LabVIEW inserts the path in the text box to the right of the Browse button. You can edit the path in this text box. When you select a path, LabVIEW normally searches that directory but not its subdirectories. You can make the search hierarchical by appending an asterisk (*) to the new path item. For example, enter LabVIEW/*, LabVIEW\*, or LabVIEW:* to search LabVIEW and its subdirectories.
The issue I have is that I have a project in a directory structure defined by a configuration control program i.e:
Y:\Test Equp\Project\Modules\Library\MyLib\* (there may be one or more sub folders contain VI's).
Y:\Test Equp\Project\Modules\MyApplication\* (there may be one or more sub folders contain VI's).
On the target the structure might be:
C:\Final\Library\MyLib\*
C:\Final\MyApplication\*
The issue is when I copy the files from Y: on my PC to C: on the PXI rack and open the top level VI in "MyApplication", LabVIEW cannot see the files in the "MyLib" until I tell where one VI is in each sub folder in "MyLib". This is a pain, specially if I make changes and transfer the file back to my PC as I have too go through the process again!
If I can spec a search path for the library files then it should just find them on either my PC or the PXI rack...
Thanks
The location of subVIs is saved with a VI, and it's a relative path. Since you are moving both directories there shouldn't be an issue finding the subVIs when you open the top-level VI, so it's not clear why there's an issue here. Are you loading VIs dynamically?

Including a LLB into the Teststand search path

Hello everyone,
on a testsystem I am using Teststand 2013 and Labview 2013. There are different measurement instruments in my system and right now I have all the VIs for controling these instrumtens saved as VIs on my system. Now I want to change this into an LLB. But when I do that, Teststand is no longer able to find the VIs inside the LLB, although the LLB is in the serach path of Testand. Since a lot of Sequence files access these VIs, it would be a lot of work to manually edit each VI call. Is it possible to include the LLB into the search path?
Thank you very much for your help!
Felix

Hi,
The search within a LLB is not supported within TestStand.
You need to update your vi path in the step settings like "MyLLB.llb\In An LLB.vi"
i.e. modify the path as llbname\\existingviname.vi.
If you put the llb in a relative path it should be fine.
Regards,
Ravi

Working on a mix on a different computer from the FCP project.

Hi,
I'd like to know the best way to work on a different computer with a multitrack project sent from final cut.
Marking Collect Audio Files will do the trick?
thanks in advance!

A third option is having the movie on an iBook or PowerBook and use Firewire Target Disk Mode at school:
http://docs.info.apple.com/article.html?path=Mac/10.4/en/mh947.html

[svn:osmf:] 11361: Adding a generic binary search utility ( updating project file).

Revision: 11361
Author:   [email protected]
Date:     2009-11-02 05:21:35 -0800 (Mon, 02 Nov 2009)
Log Message:
Adding a generic binary search utility (updating project file).
Modified Paths:
    osmf/trunk/framework/MediaFramework/.flexLibProperties

Hi,
try this forum: WebCenter Portal
Frank

Searching for a Project status = CLSD and open purchase orders?

Hi,
I am searching for a project status (Project Builder CJ20N) which allowed my to set a CLSD or a simillar status for settlement with open purchase orders.
This staus should allowed to process with open orders BUT not allowed to add new orders after setting this status.
Have somebody any idee? Or it is impossible?
Tahnk you in advanced for your Help.
Regards Baldy

Hi TV-kid,
while I was waiting for an answer I got to the same conclusion, so what you offers me is quite tempting actually.
I got a look to your website and it seems convincing. Still though, your case studies are in other business area, It's only a mater of good knowledge of File Maker.
I did download the test-drive last version of File Maker plus their samll Business Solution. I did read most of the documentation and the learning process would be too long to construct ourself a good crossed-data base.
I'd like to get in contact with you to look for a possible colaboration. to get private, I'd liketo do it through your contact link in your website .
To whom shall I write?
Thanks
Cheers
Cheers

Can two users work on different files of the same project?

Sorry if this has been asked already...but can two users work
on different files of the same project? How would that work? Would
it work something like this?
1. From RoboHelp 7, user A checks out the entire project.
2. User A checks in the files they are not working with.
3. User B checks out the project but can only 'edit' the
files that have been checked in by user A.
Is this how the source control works?

That's the basic idea. User A doesn't actually have to check
out the whole project, though. RSC will selectively check out only
the files that are actually getting changed. Both writers will have
a complete copy of the project on their local machines, but the
files are read-only until they are literally checked out, which is
on an as-needed basis unless the writer explicitly checks them out.
G

Office 2013 with Service Pack 1 installation error about "search path"

I have an automated installation technique that has worked fine with Office 2010 Pro Plus (32-bit), incorporating the latest Service Pack into the network administrative installation point (under \updates), adding 10 foreign languages to the network administrative
installation point, creating a custom .msp with the OCT (that goes into \updates too), editing the config.xml files, and then running setup.exe from that network administrative installation point. This works on 32-bit Windows XP clients and on 32- and 64-bit
Windows 7 clients.
For Office 2013 Pro Plus, I have built the network administrative installation point exactly the same way (original DVD files + languages + SP1 updates + config.xml updates), but the installation is failing with every type of client, all with
the same error message. The network administrative installation point is readable by the normal installing account, but I even get the same error when I login as me and initiate setup.exe manually, and I have all rights to this point.
Here's the critical point from a log file:
2014/03/11 11:53:49:691::[2372] DistributionPoint parsed. The distribution point is now set to: \\archive.ads.college.edu\archive\KBOXalt\Office2013
2014/03/11 11:53:49:691::[2372] COMPANYNAME specified in config.xml.
2014/03/11 11:53:49:691::[2372] USERNAME specified in config.xml.
2014/03/11 11:53:49:800::[2372] Setupexe Resiliency Mode is set to [PerformIfApplicable]; thus Resiliency is [disabled] for the [InstallExecutionMode]
2014/03/11 11:53:49:910::[2372] Searching for default versions of resource files under the folder [\\archive.ads.college.edu\archive\KBOXalt\Office2013].
2014/03/11 11:53:50:019::[2372] Error: GetDirectories: search path \\archive.ads.college.edu\archive\KBOXalt\Office2013 does not exist
ErrorCode: 0(0x0). Failed final attempt to load a setupexe resource file.
2014/03/11 11:53:50:019::[2372] Error: GetDirectories: search path \\archive.ads.college.edu\archive\KBOXalt\Office2013 does not exist
Type: 34::InvalidDirectory.
2014/03/11 11:53:50:019::[2372] WER element [SuppressModal] is set to value [true]
2014/03/11 11:53:50:019::[2372] WER element [P4] is set to value [InvalidDirectory]
2014/03/11 11:53:50:019::[2372] Catalyst execution finished: 03/11/2014 11:53:50. Return code: 30034. Exception caught: InvalidDirectory.
2014/03/11 11:53:50:019::[2372] PERF: TickCount=894821 Name=RunSetup Description=End function
I cannot find any references to this exact error anywhere on the Internet. Can anyone tell me what this means, and how I fix it?

As automated, the utility that runs setup.exe maps a drive letter to
\\archive.ads.college.edu\archive\KBOXalt using a kboxmap AD account, which has read access to the whole \KBOXalt tree. I used that same kboxmap AD account manually to simulate what the utility does, and hit the same problem. But here's what's
odd: right next to that
\\archive.ads.college.edu\archive\KBOXalt\Office2013 directory is an
\\archive.ads.college.edu\archive\KBOXalt\Office2010 directory, both created the same way, and the Office 2010 installation has always worked perfectly using the kboxmap AD account. I don't understand why Office 2013 is only working for an account with
read/write access, where Office 2010 worked fine for an account with only read access. Especially when the Office 2013 resource kit documentation clearly states that the account running the installation should only have read access, nothing more. (All this
KBOX stuff comes from the fact that our deployment environment is a Dell KACE KBOX 1000. However, that plays no part in the problem: ignoring the KBOX 1000, I can manually recreate the problem every time.)

Associate different vi search paths according project

Similar Messages

Maybe you are looking for