I am closing in on a solution. I know that it is something called after the main install of both Civil and the Civil Language Pack, so when the application repairs it does not call this part of the install its done by the setup.exe. Whatever is writing the cp_install.log is it, does anyone know the command that writes that log from the Civil 3D install?
I am looking at Civil 3D 2012 and 2011 and it seems to be an issue in the both of those as well as 2013.
There is a manual fix, if you uninstall and then re-install on the users account they will get the tool set. This is not the final solution I will try and get it working without the re-install.
Hope to have something in the next 24hrs.
Seems out IT guys resolved the problem. I'll see if i can get them to share there secrets!
NJDodd, you are pushing out your install via SCCM?
NJdodd i just realised you have actually got your deployment working.
Well we had to completely uninstall and re install to fix on the user end. There doesnt seem to be any way around that. Let me know if you develop a solutio1
Oh no our deployment isnt working, we are sending out via SCCM 2012, at the moment we are having to uninstall and install again as the user to fix on case by case as it seems you have worked out.
Now we do a repair of all our AutoCAD software on the first run as we have some custom software that needs to do so on first run for all users but that is not fixing this tools error, the repair only calls the MSI not the full setup.exe deployment.
So I have summised that the Autodesk setup.exe is running something else, whatever is writing that cp_install.log, I turned on windows installer logging on the machine and am running process monitor as well incase its not an MSI. I hope it is an MSI as then I dont have to wittle down 5million + lines in the process monitor log of the Civil3D install.
Anyway, back to it. Gotta get this solution ASAP.
I think I have found it, that little sucker was hard to track down. Can't believe this has lasted 3 civil 3D builds.
Now to leave you hanging, I will write it up tomorrow. Right now I'm at work way too late to bother having a crack at the full write up this needs.
Ok so its a problem with the condition statement on the cp_remove custom action in the C3D install.
In your network deployment (i assume you used autodesk network install tool thingy) go to the folder
adminimage\x64\c3d and find the .mst file edit the c3d.msi with Orca and apply the .mst file which should share the name of the network build you created. Mine was called C3D-CIV12x64.mst, anyway then go to the InstallExecuteSequence table and change the Condition Cell for cp_Remove.8D55C016_8619_4164_89F4_9377D0E21953 from Installed to REMOVE~="ALL"
The issue is that that custom action to remove the Content Pack (cp) is being run on repair so I think this breaks 2011 and maybe 2013 if you have both installed and 2012 repairs. I will have a look through both 2011 and I think we have a 2013 deployment build but we haven't started sending it out to users yet.
You may also have to force a repair when the user first runs. As I mentioned earlier we do this already because of a piece of software our company created so we already have that done.
If you have anymore questions let me know.
Oh yeah I have the solution. It involves editting the Install sequence through a Transform. I am flat out right now, I can do a write up soon. For anyone that knows how to edit MST files through Orca or any other program I can provide mine for reference only.
Reckon you can provide that MST file and a few hints as to what params are the cause of the problems.
Autodesk, surely there is a more clean solution for this.