We recently created deployments of 2013 Civil 3D (32 and 64 bit) and pushed out (with SCCM) the install to several machines. It was a success however the users are missing assemblies in their tool palettes. I have searched but only found the issue in 2010 and 2011. How can I resolve this in 2013?
Thanks
Nick
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?
Talk soon.
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
Regards
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.
Cheers.
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.
Regards
I may not be able to provide the MST in the end, sorry guys, my boss says no. But i will go into detail of what I did, its all to do with the conditioning and sequencing of their custom actions that build the user profile.
So the tools are related to the Content Packs, through searching logs as the application was running and after it was done installing I found that it was CP_install.log we were interested in so then any cp_(actions) in the Civil MSI were under scruitiny.
At first I thought it was that cp_Remove.8D55C016_8619_4164_89F4_9377D0E21953 was conditioned as Installed which would mean it would run the cp_Remove custom action on a repair, which seems off to me. But then I found later in the InstallExecuteSequence there is a cp_Install.8D55C016_8619_4164_89F4_9377D0E21953 which was conditioned with REMOVE<>"ALL" which should run on Install and repair so you would think that might work as even if its removed this action will install it again. Well I am not sure how this custom action works or what it is calling, perhaps the remove takes time and keeps the dll it is using in use, its the same dll, so the install cannot kick off and fails, not 100% sure on that.
In the InstallExecuteSequence table change the condition field for
cp_Remove.8D55C016_8619_4164_89F4_9377D0E21953 to REMOVE~="ALL"
and for cp_Install.8D55C016_8619_4164_89F4_9377D0E21953 to NOT Installed OR REINSTALL<>""
I thought I also changed the sequence for
cp_Profiles.8D55C016_8619_4164_89F4_9377D0E21953
cp_Shortcuts.8D55C016_8619_4164_89F4_9377D0E21953
cp_Cleanup.8D55C016_8619_4164_89F4_9377D0E21953
to run after InstallFinalize as well but it seems to be that way in the MSI already, unless I mistakenly editted the MSI. You can check that in your installs.
This is all for the c3d.msi in AutoCAD Civil 3D 2012, I am using the C3D-CIV12x64.mst (CIV12x64 is what we called our network deployment when we generated it using the Autodesk deployment build tool) its in the same folder as c3d.msi in Adminimage\x64\c3d.
Our businesses application manager for autodesk products was in Vegas for the CAD software convention last week and brought up that the installations were crap and he got word that Autodesk were building new installs for 2014 from scratch and as we are using SCCM 2012 they would be giving us the installs in Jan early to take a look so we can give feedback before April release.
There are other issues with Autodesk installs, especially the installs built by the autodesk network deployment builder, like that they are Admin installs and can break the file path limit rules and being seperate files can kill SCCM when deploying.
We have been re-cabbing these up through dodgy ways, but it has worked so far.
Any questions let me know.
Tell me about it.
I have been simply deploying autocad vanilla and scripting everytihng afterwards for the last 3 years.
SCCM has jsut opened up a whole new barrel of b*ll**** that jsut aint fun.
Thanks for your help
Regards
The key also is once its deployed in this state it needs to repair under the user profile to work.. which means if the user has already run civil from a previous deployment that was broken you need to force a repair once this new one is installed. Which can be annoying.
You need to uninstall from programs and features after the working install is up on the SCCM server then it will download the new version and install and then if the user has already run Civil they need to get the repair to kick off.
deleting the civil 3d files in the user profile folder c:\users\<username>\local\autodesk\civil3d
c:\users\<username>\roaming\autodesk\civil3d
registry HKEY_CURRENT_USER\Software\Autodesk\AutoCAD\R18.2\ACAD-A000:409
delete the whole key
then it should repair and be all good.
If you have any further questions let me know.
Thanks for all your work NJDodd but unfortunatly it didn't help me. I am still missing the assemblies on my Tool Palettes. Even after installing on a new system with the modifications you've mentioned in the mst mentioned by you.
I've also tried to do the same for Civil 2013 but when I start the application the splash screen to configure Civil comes up and I need to enter my serial number again. For some weird reason it fails while the same serial number is being accepted when I start a new network deployment.
I guess I have my hopes on Civil 2014, that Autodesk finally has fixed their lousy setups...
Just curious jsutforthispost, how are you making the deployment. From cd's? From image?
Yeah I haven't looked at 2013 yet...
The only thing left is, did you force a repair in the user account you are testing for civil 2012?
I might try and remove our company info from the MST and let you have a crack with it.
Oh crap so sorry guys, realised I was looking at an early not completely fixed final MST, I got the one from my SCCM deployment source location and there is the change to those three actions I mentioned earlier.
this is what I said.......
-----------------------------
I thought I also changed the sequence for
cp_Profiles.8D55C016_8619_4164_89F4_9377D0E21953
cp_Shortcuts.8D55C016_8619_4164_89F4_9377D0E21953
cp_Cleanup.8D55C016_8619_4164_89F4_9377D0E21953
to run after InstallFinalize as well but it seems to be that way in the MSI already, unless I mistakenly editted the MSI. You can check that in your installs.
---------------------------------
Sorry I was distracted as I am working on about 4 other applications at the moment. So the key is that those cutom actions have to be moved to before InstallFinalize as those custom actions cannot be run outside. So even yesterday I didn't see it staring me in the face even though I knew i'd done something with them and I only just fixed it about a week or so ago.
I am pretty sure because the custom action is a DLL from the Installation then the binary it is trying to call is not available outside of installfinalize. I have been doing too many vendor installs and boring SCCM installs that I forget my training sometimes.
These are the changes I made in the installexecutesequence table, I used Wise Package Studio with the MSI Script View, its a matter of selecting the custom actions and pushing the up arrow. Easy.
In the tables it is...
cp_Profiles.8D55C016_8619_4164_89F4_9377D0E21953 --- Sequence= 6650
cp_Shortcuts.8D55C016_8619_4164_89F4_9377D0E21953 --- Sequence=6675
cp_Cleanup.8D55C016_8619_4164_89F4_9377D0E21953 --- Sequence=6687
so im not sure if thats the same as 2013. It's easy to change that in Wise package studio in the MSI script view, a bit harder in orca and i think also hard in installshield admin studio.
Anyway good luck, let me know how you go with this info. So Sorry for the mixup.
Thanks for all your help NJDodd but I can't seem to get the tool palettes working in our 2012 release. Did everything you've mentioned in your last post plus in the earlier post but still am missing the metric palettes for example. Also did a repair with my test user but no joy.
I have attatched the mst I've just for this testing, I don't know if you have time to look at it. If you don't it's no problem ofcourse. I had to rename the extention to txt otherwise the forum would not accept it so if you download it you have to rename it back to .mst
OK so it's slightly different for Civil 3D 2013 but also I think for Civil 2012 I think it is more simple than I made it in my solution.
I have a feeling all that is needed to fix it is to find the custom action in C3D.msi cp_remove******** and change its condition to REMOVE~="ALL"
In Civil 2013 they have moved the content pack to its own MSI in the Language Pack folder.
In the deployment folder it is in this path
AdminImage\x64\en-us\C3D\C3DPS.msi
the custom action is the same and has the wrong condition again and the remove of the content pack will run on a repair. once again change the condition of the custom action cp_remove to REMOVE~="ALL" and it should fix the issue.
Now I am still having issues with it for a network deployment using SCCM 2012 SP1 as it runs the installs as the system account. But the manual install from the setup.exe once I've made this change it works fine.
So frustrating, I am hoping to get in contact with AutoDesk guys to get them to maybe get onto this and fix the condition in their build and it will just work first time.
Just dont use SCCM.. get past it until they repair it.
You shouldnt have to go back and fill in the holes on the road you paid for.
BK
Can't find what you're looking for? Ask the community or share your knowledge.