BIM 360 Linked Revit Models use Local Cache Path

We've been running into this situation lately. Linked Revit models start using an individuals collaboration cache location for the path instead of the project's BIM 360 location.

At first it seemed that we could resolve it easily by applying the update for Revit 2020. Most of the active projects I deal with are still based on Revit 2020.

It appears that a fair number of firms are deploying "even" years and skipping the "odd" years. The larger the scope of deployment seems to have some influence over that choice. I've been working with 2021 in smaller situations though, wishing it were true everywhere...I digress.

Autodesk acknowledges the issue and has this ARTICLE to contend with it.

Wishing it were that simple, we are still running into it. Naturally there is another ARTICLE that mentions they are still researching the issue but that using Force Relinquish (BIM 360 Manage Cloud Models option) can cause this situation too. This requires us to clear the collaboration cache for a user who has forced us (haha) to use Force Relinquish. We are still in the diagnosis phase ourselves so we're not convinced of anything yet.

The article also tells us that using Force Relinquish should be a last resort and not recommended for routine use. Autodesk article says, 

"This is happening because somebody has used Manage Cloud Models to force relinquish that user from that link, which breaks the link in the host model for the affected user."

"Note: Force Relinquish is a destructive operation and should be used sparingly! It is intended to be used as a last resort when the user to be relinquished is unavailable for some reason."

"If someone has been forced out through Force Relinquish, then all the changes that they have not synced, become orphaned and lost. While the central model will be unaffected by the use, people can lose work (and have to close and reopen the model which will be slow)."

"It is better for the user to open the model and use Relinquish All Mine to relinquish their permissions rather than using the Manage Cloud Models dialog."

Okay, that's fair. However the new named user subscription based model "forces" this option on us (not haha) at large because we can't pretend to be another user anymore. As soon as we log off to become that user we lose our Revit session too. Catch 22

It would be nice if employees didn't quit and go elsewhere or earn a dismissal. It would be nice if 3rd party applications didn't need to borrow a workset on our behalf and then refuse to return a workset without our knowledge. It would be nice is 3rd party applications that do automation didn't require their own username to run quietly in the background and then fail to return a workset from time to time.

That world is where we can find pink unicorns with diamond encrusted saddles, at least I think that's where they are, I could be wrong?

Right now clearing a workset conflict in Revit Server projects is not nice. BIM 360 at least has Force Relinquish...but now we're told you really shouldn't use it because it might wreck your linked model paths. It starts the kind of internal conversations that make EyeTee license management "heads spin". Nobody wants users to start sharing log in credentials do they?

Additional Collaboration Cache Article

Web Update 7 is Innocent

A quick follow up post. I was wrong. What I thought was caused by the update is actually caused by the Snap setting Snap to Remote Objects being off.

I must admit it is a bit mystifying since I never turn it off or at least I can't remember I time when I wanted to nor do I remember doing so. Regardless when support gurus Trey and Danny challenged me with their questions I found it was off.

Fwiw, I'd prefer that it didn't impact grid and level placement editing behavior regardless.

At least it prompted me to deal with a couple hours of windoze updates I'd been postponing.

AUGI | AEC EDGE Spring 2010 issue is posted

The next issue of AUGI | AEC EDGE is finally out. Each issue is intended to arrive at the end of the season. Unfortunately my workload made it harder than usual to meet our intended deadlines. All that is behind me now...it's posted!

Thanks again to the authors who make each article possible and this issue's authors are:

Lee Ambrosius, Christian Barrett, Elizabeth Chodosh, Lonnie Cumpton, Doug Eberhard, Jon Allen Gardzelewski, David Harrington, Trey Klein, Glenn Jowett, David Light, Jay Polding, Philip (Chico) Membreno, Keith Rice, and Daniel Stine

Now on to prepare for the next issue.

[Amended 9:00 PM] The magazine cover image at the magazine web site is still pointing to the Winter issue. The link on the left frame that says Online Version works. That and you can download the pdf versions.

Hotfix Revit 2010 Platform - Walls

The Autodesk Update site has a new Hotfix item. The description is a bit vague: This hotfix addresses issues related to deleting or modifying walls, a crash may occur.

You need to make sure that you read the Readme file. You need Web Update #1 installed first too. There is a hotfix for 32 bit and 64 bit versions. Surprisingly low tech patch process. Same hotfix applies to each version so just repeat for the others if you have them too.

It's a good idea to keep an eye on this site every now and then.

[Edit: Aaron Rumple posted at AUGI that this hotfix disables the 2009 UI Revit.ini hack that permits users to use the 2009 user interface instead of the Ribbon. Stay tuned to the thread or here for an update.]

View Reference - Customization

If you want to create your own view reference family you can start by editing the one that is provided with Revit. You can also start with a Generic Annotation family template and then assign it to the View Reference Category via Settings menu > Family Category and Parameters.


The View Reference family is a system family that can have different annotation families assigned as a type parameter. To use your own view reference annotation you can alter the existing one to use your family or duplicate the existing type and then assign your new family to the new type you just created.

To actually make the change you need to start the View Reference tool > click Properties > click Edit/New then either change the View Reference assigned or click Duplicate to create a second type to use.


Now you can use either the original or your new view reference.

Personally I think that a View Reference tag should show up in the Settings menu > > Annotations > Loaded Tags dialog just for the sake of consistency.

Dependant Views and Hide in View - Elements

The new feature (Revit 2008 products) Duplicate View > Dependant Views is intended to provide an exact copy of the parent view but allow you to crop the view differently making it easier to document in an overall view but show partial plans on sheets. This makes it simpler to manage annotation and avoid the copy/paste process of putting annotation in various duplicate views.


Take care when you use the new feature (Revit 2008 products) Hide in View however.

If you use this feature either in a parent view or a dependant view the hidden element is only hidden in the view you do it in. The other view(s) are not affected. In my opinion, this is not consistant with the implied behavior of parent/dependant views. I believe that when we hide an element in a parent view, the dependant views should also have that element hidden. The view specific behavior should be limited to non-dependant views. As it is now, remember we must un-hide/hide this element in each view.