PDA

View Full Version : Deploying Revit



bimologist
2006-02-08, 10:32 PM
We just posted a new build of Revit Building on www.autodesk.com/revitbuilding (http://www.autodesk.com/revitbuilding)

The new build is primarily a service for the localized versions of Revit Building 8.1. There is one additional issue that has been resolved for the benefit of all users; the problem that the wall join on one end of a wall changes when the other end of the same wall is edited.

thanks,
tanja
I am new to Revit, but I am still trying to struggle with the idea how do I send an update out to all the installed base. I have heard stories about people working on worksets should all be on the same build and I had voiced my concern to you at AU2005 as well. I mentioned to you and Julian that I am not opposed to constant builds (infact its great tha tyou keep fixing errors) but it is not easy to deploy the builds as patches as you have to uninstall the previous build then install the new one.
I have not gotten into depth yet installation wise, but I think that action overrites your REvit.ini file which user may have customized since we are at the initial stages of Revit implementation with 2 huge arena projects in the pipeline slated for Revit.

I am also struggling with Network deployments not installing OTB content locally, they assume that the network location already has it (which is a great assumption,) but if I select the local ALLUSERPROFILE\ADesk\Revit 8.1 as default, there is no content there,
Like ADT deployment, you have a choice of installing the Local content or not using the Network deployment wizard, i.e. Default, Shared etc. Shared does not install the content (though it has its problems if the directory is locked)

So for future please consider some strategy of deploying updated builds easily which preserving the user settings by using Patch technologies, etc.

thanks

Nauman Mysorewala
GBBN Architects.

tc3dcad60731
2006-02-08, 10:47 PM
I thought I was the only one that could not find anything on the new build for series 8.1. I will follow that link and hopefully get the information that I need.

Simon.Whitbread
2006-02-09, 06:52 PM
I have not gotten into depth yet installation wise, but I think that action overrites your REvit.ini file which user may have customized since we are at the initial stages of Revit implementation.
Hi,

We have chosen the route of network installation, its by far the easiest way of updating. These builds are not patches however and are complete installs. Handling this through Group Policy makes things really easy. Because of the numbers involved and the way people tend to move around in our practice, we standardised our shortcuts in AutoCAD a long time ago. Hence we have done this in Revit as well, managing the 'KeyboardShortcuts.txt' and 'Revit.ini' in the same way. They are located on the server and copied at time of installation with the aid of Group Policy. Any changes to these (ie: new or updated shortcuts) can be pushed out to users efficiently.

GuyR
2006-02-14, 07:31 PM
Simon,

Do you not allow each user to customise the keyboard shortcuts and ini file?

Guy

Simon.Whitbread
2006-02-14, 08:54 PM
Because Revit doesn't yet support user profiles as Autocad does, allowing user files to be stored somewhere other than the program folder, it would quickly become unmanageable to let users customise their shortcuts. Yes they can chose options for changing library paths, but in an office where people move around regularly, we promote the 'JASMAX' shortcuts.

At the moment, these are OOTB, with the exception of the number keys for 3D view manipulation



Simon

GuyR
2006-02-14, 09:24 PM
So ini files aren't unique?Damn,I have been using ini files for storing certain info(for API). Looks like I'll need to change this.

Guy

Scott D Davis
2006-02-14, 09:33 PM
Another problem with everything being stored in the Program Files folder: Here, no user has "rights" to write to this folder on their machine. That means when you go to the File pulldown in Revit, you get no "history" of recent files opened at the bottom of the files list.

GuyR
2006-02-14, 10:02 PM
Here, no user has "rights" to write to this folder on their machine

Then how is Simon allowing users to alter library paths. Which are stored in the Revit.ini file?

Guy

Scott D Davis
2006-02-14, 10:21 PM
Must be that he creates the "default" INI file, then pushes it out to every machine. Each of Simon's users then has rights to modify that folder, including when they change library paths, it changes and saves the INI file.

bimologist
2006-02-14, 10:22 PM
Then how is Simon allowing users to alter library paths. Which are stored in the Revit.ini file?

Guy
I guess If I read him correctly he does not allow it. Maybe open up just the REvit.ini file.

I am pretty open to customization. What every makes the user productive. I add project paths in the library to take me quiclky to my project dir etc for imports ...

Simon.Whitbread
2006-02-14, 11:39 PM
Must be that he creates the "default" INI file, then pushes it out to every machine. Each of Simon's users then has rights to modify that folder, including when they change library paths, it changes and saves the INI file.

Thats exactly how its achieved. The default is customised to start with, then along with the keyboardshortcuts file they are pushed out to users. They need to have modify rights to that folder, otherwise their username for workset access would be the same. The keyboardshortcuts are published as and when there is a change.
Although the user could edit this file, the program files folder is hidden, and access to it using explorer is denied using Group Policy

Scott D Davis
2006-02-15, 12:08 AM
They need to have modify rights to that folder, otherwise their username for workset access would be the same.
ughhh...another reason why much of these settings needs to be moved into the Documents and Settings area for each user. Why can't the worksets username use Windows authentication and grab the login name?

Simon.Whitbread
2006-02-15, 01:25 AM
Why can't the worksets username use Windows authentication and grab the login name?
I believe it does - but its then saved back to the revit.ini file

Scott D Davis
2006-02-15, 01:27 AM
Ahhh, yes. I think you are right!

Simon.Whitbread
2006-02-15, 02:35 AM
Could be that this is a wish list item, I've seen that it has appeared on at least one thread there but might be an idea as a poll... Think I'll go there.

As for a BETA of 9.0... I'm on the list

bimologist
2006-02-15, 03:15 PM
Could be that this is a wish list item, I've seen that it has appeared on at least one thread there but might be an idea as a poll... Think I'll go there.

As for a BETA of 9.0... I'm on the list
Well They have been pushing Windows Logo compliance in the Acad line, why not here. they do it partially for the content if it is installed locally or on the machine that creates the deployment.

So wish list items:
1. Allow a Users folder in %USERPROFILE%\APPDATA\ADesk\Revit.....where the Partial Revit.ini is STORED. or maybe the whole of it and then there is a Userdatacache like acad where if a new user logs into the machine the canned Revit.ini file is copied to the %userprofile% folder. similar to what acad does.

2.Keyboard shortcuts be that way too. i.e user based.

3. Maybe use Registry instead of ini. or both

4. NOT wipe out the Revit.ini when a NEW build is installed. This could be aleviated by moving it to the userfolder. This comes under the SECTION of FREQUENT UPDATES =AWESOME, but UPDATING procedure really needs improvement. PATHING vs COMPLETE uninstall and reinstall which wipes out your REVIT.ini customizations. this could be a problem GuyR and Danny since they write a lot of custom code for Revit.

5. Provide local install of content even though you specify network deployment. Network deployment does not mean that the libraries are not to be copied locally. THE OOTB libraries are not touched in our office. Anything we change from OOTB, goes on the server library. It has to do with how they install and the CONTENT.RCL file that is generated by the installer and packaged inside the Deployment.msi file THe Content.rcl tells the ContentLoader that it had already installed the content except the help which is not checked off as installed. Well it is INSTALLED on the Local Machine where the deployment is created but not on the machine the deployment is to be installed. All I have to say here is I love ORCA the whale!. took care of my issue. But they need to fix the deployment and make it a little bit more flexible. Have it look for the content on the server where you deployed rather than download , well it does put alt path as the server so it does look there first.. And please get rid of UNC pathing. allow both in your deplyments.