Robot 2013 SCCM Task Sequence deployment caches MSI in wrong location

[Anonymous]

I recently deployed a number of products from the Autodesk Education Master Suite 2013, including Robot, to 10 computers. I deployed it as a step in an SCCM 2007 Task Sequence, as opposed to including it as part of the image or deploying it after the task sequence has fully completed. I then ran into a problem where the MSI for Robot is cached in the wrong place: c:\_SMSTaskSequence

Because of this, when Robot is started up for the first time for a user and tries to configure itself via the cached MSI, it fails as the files cannot be found in the c:\_SMSTaskSequence directory. There are some files in there, but nothing for Robot. I haven't yet run into this problem with any other Autodesk 2013 programs, so they seem to be aware of the system environment during the task sequence and cache the MSIs in an appropriate location.

[Anonymous]

It seems like this problem is not limited to task sequence deployments. I just created a new deployment package containing only Robot and placed it on a network share. I installed it by running the created shortcut. When a user runs the program, it then wants to access the MSI from the network location where Robot was installed from. Since I don't want students to have access to this location, I'm not really sure how to proceed.

[Anonymous]

With some further testing, I found that this happens even when installing from the supplied USB drive. If I don't have the USB drive in when I start the program, it says that it cannot find the MSI.

I did discover one thing, though: Robot will run ok under the user account of the user who installed it. So for the time being I will create a shared user account just for installing and running Robot. However, this solution is not ideal, and I'd appreciate any help that anyone can offer to fix this. Thank you!

[Artur.Kosakowski]

I recently deployed a number of products from the Autodesk Education Master Suite 2013, including Robot, to 10 computers. I deployed it as a step in an SCCM 2007 Task Sequence, as opposed to including it as part of the image or deploying it after the task sequence has fully completed. I then ran into a problem where the MSI for Robot is cached in the wrong place: c:\_SMSTaskSequence

Because of this, when Robot is started up for the first time for a user and tries to configure itself via the cached MSI, it fails as the files cannot be found in the c:\_SMSTaskSequence directory. There are some files in there, but nothing for Robot. I haven't yet run into this problem with any other Autodesk 2013 programs, so they seem to be aware of the system environment during the task sequence and cache the MSIs in an appropriate location.

---

Robot 2013 does not support SCCM. Please use GPO instead.

[Anonymous]

Thank you for the response. Unfortunately, as I stated in the other posts, I experienced the same problem with a non-SCCM deployment and even with a normal install from the Autodesk supplied USB drive. This happened on multiple computers.

[Artur.Kosakowski]

Please try the following steps:

1. Create a deployment on a network drive as Admin

2. Run installation on a local computer

3. Run Robot on a local computer as Admin and close it (the access to the network drive should no longer be needed)

4. Create a new user on a local computer

5. Run robot as the new user

If you find your post answered press the Accept as Solution button please. This will help other users to find solutions much faster. Thank you.

[Anonymous]

Thank you for the response. I created a deployment on a network drive, then installed it on a local computer as an administrator. Robot ran fine for that admin user, and when I created a new file I did not see any dialogs about Robot trying to find the MSI.

I then logged off and logged on as a different domain user who has never logged onto the computer before, but when I created a new project I got the dialog box asking for the source MSI location ("The feature that you are trying to use is on a network resource that is unavailable").

[Artur.Kosakowski]

Have you created the network deployment using a Mapped Network Drive for the deployment path rather than a UNC path and the same drive isn’t mapped for the domain user? If yes, could you try with the UNC path please?

[Artur.Kosakowski]

Please check if this helps:

if the Domain User accounts doesn’t have permission to the location where the deployment was installed from, they should have at least Read permissions.

[Anonymous]

Sorry for not responding yet; I had a big problem turn up in one of the other computer labs that required my full attention. I understand what you are saying, but why do users need to be able to access the original installation source, even when I installed from USB? No other Autodesk product has exhibited this behavior, and we don't want students to have access to the network share where the installation files are. If there's no other option then I guess that I will have to do it this way, but I'm just confused as to why its necessary. Thanks!

[Anonymous · Accepted solution]

I was able to get this working after creating a network deployment using UNC paths on a share that users have read-only access to. However, it still strikes me as odd that this problem occurs even when installing from the Autodesk-supplied USB media, and it's not desirable to our organization to have to provide access to the installation files for all users. If this could be fixed in future releases of Robot, that would be great.