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

How Often to Synchronize with Central - SwC

Grist from a recent support conversation..."How often should we use Synchronize with Central (SwC)? We have some users doing it every minute."

Well....every minute seems a bit much...but...

The number of people actively working on a file affects the truth of the statement too. Every 30 minutes, for example, is too infrequent in my opinion. My own habit is to SwC as often as I complete any given task. I tend to take small bites, tasks that are 1-10 minutes, and SwC as soon as they are done.

More frequent SwC is less data transmission than every 30 minutes, potentially. Replacing or reloading a title block for 1,000 sheets is not a small task and probably ought to be done at lunch, advising people to create new local files afterward. Otherwise each sync will need to needlessly update each local file's copy of the sheet's title block too, for everyone. If that is done while they are all away they just inherit the new version of the project with their new local file.

It's all relative though because the transaction comparison between syncing that kind of change and closing a model and opening it later is subtle. In fact opening a file again might be slower, but reasonable, depending on how many people are involved. It can be justified though, especially if they are out of the project anyway such as out for lunch or after hours etc.

I think it is more important to be aware of other users also using SwC, than imposing a specific time requirement. When more than one person uses SwC at the same time Revit has to parse those changes and it does so, more or less, in a single threaded manner, not like a multi-thread OS (though they are improving that all the time) doing simultaneous tasks. It has to reconcile changes and move to others once it is satisfied it can finish successfully. The more people forcing Revit to do that at the same time the slower it gets for everyone. That's where the advice to schedule or increase the time between SwC came from. One client decided to build their own tool so users can see if someone is syncing. A button on their Quick Access Toolbar parked next to the SwC button is red when someone is syncing and green when nobody is. Green means go for it.

Any sort of "Every 30 minutes" rule is often an over simplification, a rule meant to be easy to implement. In practice it can be just as harmful as helpful. If I slip and go 60 minutes or longer then that starts to slow down SwC times for everyone else too. Pushing and pulling data through a pipe takes time, smaller chunks of data generally take less time and less time to reconcile with the model too.

I'd focus on developing awareness of other users syncing as the priority and it's increasingly important the more users that are working on the same project file.

Add a Comment using Synchronize and Modify Settings

Whenever we need to use Synchronize with Central (SwC) I advocate for using the button for Synchronize and Modify Settings every time.

Doing so allows Revit to present us with the Synchronize with Central dialog.

I encourage everyone to take a moment and type a brief description in the Comment field provided. What motivated you to use SwC just now? That's the gist of what should be recorded there. I find that people are more receptive to making a habit of it once they see it can prove to be very useful to just about everyone working on the project.

We can review the comments anytime we choose to, even if we don't have a project open yet. That means that anyone who can at least fire up Revit can review project comments even if they don't really need to do any work in Revit.

Yes, the Show History button on Collaborate ribbon is awake even if no project is open. Click Show History, browse to the location of the relevant Central File and click Open. The comments are presented to us like this.

I doubt it is hard to imagine how having everyone on the project team recording comments (time stamp and username are stored automatically too) can be helpful for diagnosing issues, checking the status of tasks, and even a quick review of user activity on a given project file. It will also become obvious who isn't playing along pretty quickly.

I also recommend that we never use the other button for Synchronize Now (that's why I put the red X on it in the image above). It doesn't present the dialog so there is no opportunity to store a comment and equally important is that is does not relinquish User Created worksets automatically.

If you pay close attention you'll notice that all of the other kinds of worksets are automatically checked when the Synchronize and Modify Settings dialog is open. Those other worksets are relinquished with Synchronize Now, not User Created worksets though. If you use Synchronize Now and you've ever been accused of retaining ownership of these worksets...that's likely why.

If it helps:

Green Arrows in Circle SwC = Good!!
Lighting Bolt SwC = Not Good!!

If you're interested in taking a peek at Kinship's features you'll find that these comments can be reviewed at will with just a browser.

Create New Local is Disabled

I've written about this in the past, like THIS ONE. Today I noticed another circumstance where the option is disabled even though it shouldn't be. When we browse to open a project we can click on a file listed among the contents of a folder. If we do that then Create New Local is enabled and checked by default. At least that's true if other circumstances are not preventing it, like those described in my other post.

What I saw today is that if I choose to type some of the file name in the file name field Windows will supply me with a list of file names that begin with those letters, cool Windows behavior. If I select the correct file using that list then Create New Local sleeps through the effort and fails to become enabled.

Want to see it happen?

Revit Viewer and Worksharing

Reading a thread at Autodesk's Revit Community forum David reminded me of the quirky issues related to the Viewer when worksharing is being used. If someone launches Revit Viewer and then tries to open a project that has enabled worksets they'll get this warning.

When the file is opened and they try to print, export or save they'll get this warning even though they haven't DONE anything...but Revit has made changes to the file in order to create a new local file.

Okay, let's follow the instructions in the first warning message. We'll open the project using Detach from Central. Sorry, "Do not pass Go, do not collect $200". That process also changes the file. Still no export, save or print for you!

The ONLY way we can use Revit Viewer to open a project with Worksets enabled is to open the Central File itself, by un-checking the option to Create New Local. This means that user is now working on the real central file with Revit Viewer.

If you do this you will likely encounter several of the messages shown in the first image. The projects I've done this with all have linked files and it seems to pop up for each link (RVT) used and once more if there are any linked/imported DWG files.

To the good, they won't be able to synchronize their work nor will it prompt them to Save when they close the file. They won't be able to edit much of anything though because they can't borrow elements. The notion of using Revit Viewer to poke around the model, do some experimental stuff within the model is off limits to Viewer mode. We are able to print or publish to DWF, because those formats don't create an editable version of the data/model.

It seems to me that the notion of Revit Viewer for workset projects is fundamentally flawed, if we're thinking of it as a way for Project Managers to poke around, do anything other than JUST LOOK at views. If we'd like them to be able to cut a section view or hide things, do anything that requires temporarily borrowing something, that's all off limits to the Viewer.

For that we'll have to show them how to use Detach from Central AND to be careful not to save that file overwriting the original project.

Getting Started with Collaboration for Revit (C4R)

Below are a couple of links that describe the process for getting your project started using Collaboration for Revit (C4R).

It all begins with creating a project using your A360 account/subscription. Naturally you've got to create an account first so this assumes you've done that. The linked page also explains how to upload your current project to the A360 project if necessary.

If you're responsible for putting your active file on the A360 Project, READ ME, it has a video too.

There is a ton of information lurking at Autodesk, just use your Google-fu.

Revit 2017 - Enabling Worksharing

The process for enabling worksets has changed with this release because Collaboration for Revit (C4R) has been incorporated into Revit directly. This allows someone to subscribe and begin using it quicker. They might even be able to do so without any (or much) EyeTee intervention.

The first evidence that there is something different is on the Collaborate ribbon tab; there is a Collaborate button next to the disabled Worksets button. There is a new Communicate panel too.

In the past enabling worksets began with clicking on the Worksets button but now we start by clicking on Collaborate. This takes us to the fork in the road necessary to permit sharing the project via A360/C4R whether we are able to use it or not, just in case. If the file hasn't been saved before clicking Collaborate we get a message asking us to do that.

Then the Collaborate dialog appears asking us to specify which method of sharing the project we need; Collaborate within your network or Collaborate using A360.

When we choose Collaborate within your network Revit enables and creates two User-Created Worksets called Shared Levels and Grids and Workset1 (like in the past) but it doesn't open the Worksets dialog (like it used to). This allows us just to get on with our work using the Active Workset (Workset1 by default). If we need to create additional worksets then we'll find the Workset button is enabled, just click it to open it (Workset dialog, as in the past.

The Communicator button is tied to using C4R. It is a separate window (dialog) that can display information about your project team activity, if you're sharing the project using A360. Imagine concepts from Worksharing Monitor combined with Instant Messaging features and that's what you've got. FWIW, it used to be able to dock inside the Revit UI but it doesn't do that now. If you've got two or more monitors you'll probably prefer it on one of them instead anyway. This is what it looks like if I'm not logged into A360 and not using it to share this project.

At some point we'll need to Save the file and like in the past we'll be warned that this is the first time we've done that since we enabled worksets; click Yes.

Remember, if you'd like to set the default Open option to Specify remember to use Save As instead of Save. You only get a chance to do that with Save As. This allows us to choose which Worksets Revit should load before it opens the project entirely. This can have a significant impact on how long it takes to load a project.

At this point we are still working in the Central File, which isn't practical to share the project nor is it advisable. I can determine that by looking at the Save icon on the Quick Access Toolbar (QAT), it is disabled and the Synchronize and Modify Settings button next to it is enabled. The project's file name listed on the Title Bar doesn't include my user name either. By the way, we need to SwC to relinquish our ownership of the User-Created worksets properly. The only way to do that is to use SwC (Synchronize and Modify Settings), via the dialog that appears. The Synchronize Now button does NOT do that.

Now that worksets are enabled and relinquished we need to close the project so the team can get started by creating their Local Files. When I browse to the Central File to start work I need to make sure that Create New Local is enabled and double check the Open option is assigned to Specify.

Remember doing so will cause this dialog to appear before Revit begins opening the project further.

Okay, now get to work; in your Local File!

Worksharing Display - Owners

The first thing I do when a project is open, to get a sense of things going on around me in the model, is to toggle on Worksharing Display - Owners (see image). That gives me a quick snapshot of who else is working on things around me.

If I see a color on anything I thought I'd start working on then there is no point attempting to edit those, I'll just get a warning from Revit in response. The mere presence of colors indicate other people are around, in this context. Hovering over one element brings up a larger tool tip than the usual information we get, including which person is currently editing it.

I use the Worksets option for Worksharing Display just to see if things are obviously assigned incorrectly. Again, hovering over any element tells me what workset it is assigned to in either the normal tool tip (first thing displayed, unless Design Options are involved too) or the expanded one for Worksharing Display.

I think most people forget about or overlook the Gray inactive worksets option too. That helps me cope with my nemesis Active Workset because it reminds me which workset is active because the things around me are either bold or not (see image).

Prompted by a reply to a thread at RFO.

Worksharing - Loading Content Part 2

In my previous post I recommended a point person be assigned to manage the loading of content for a team. That might sound like a beauracratic minded recommendation. Not me at all. It is more a matter of self preservation, wishing to avoid having to fix the resulting duplication before it becomes a bigger problem. As such there is a another minor measure we can take to help catch the issue when it occurs and fix it.

Always use Synchronize with Central (SwC) immediately after loading new families or types (or duplicating system family types). Don't place any instances.

If we can't get a single person to manage this loading then using SwC immediately afterward will increase the odds that a warning message will appear as soon as the transaction is completed. This does assume that we all develop this habit. If the warning appears than we need to examine the new family(ies) and or type(s) in the Project Browser and resolve the issue.

The goal is to avoid creating the duplicates and even more importantly using them in the project.

Worksharing - Loading Content

I read Jason's post this morning and he describes a classic worksharing gotcha. Unfortunately he hasn't identified the true culprit. I'm referring to this part of his post specifically.

One of our most notorious examples is the infamous Break Line. Each drafting view we imported had a copy of the break line family. By the time anyone noticed, the project model had “Break Line (1)” through “Break Line (22)”.

What he describes is the result of worksharing and multiple users loading the same family in their own local files. Revit sees multiple versions of the same file being loaded from different local files (users) and seeks to protect them by renaming the other versions it encounters. We see this sort of message when it happens.

This error and situation is easy to replicate.

• Two users open local files for the same project
• Each user loads a new family and the same type
• Each uses Synchronize with Central (SwC)

The first person to sync will be successful without an issue but the second person will receive a warning about the family being renamed. If this is repeated enough, and by enough users at the same time, we could end up with family22 like he described.

For example, if eight people all introduce the same new family to the project then by the time the last person uses SwC there will be eight versions of this family listed in the Project Browser. This is what the Project Browser looks like after just two users think they both need to load a new double door and type.

Jason's post is focused on cleaning up after oneself and it IS important but it is also important to manage the loading of content and harvested details. It is equally important that people understand why these extra versions show up in the first place. Each time someone uses Load Family or Insert from File they must reconcile the warnings that appear before anyone has a chance to begin using the wrong version of the families that are duplicated.

I think it is worth restating that the subtlety of this issue is that this only happens when more than one user is introducing the same new family to the project (via their Local Files).

Once the family is part of the project (defined in the Central File) Revit doesn't get confused anymore. Here's what happens when I introduce the Break Line family he mentioned to the project via two users. Keep in mind that there is no Break Line family defined in the Central File at the moment. Each user loads the family, into their Local File, unaware the other user is doing it too. The first person to use SwC is fine but the second user sees this message (I expanded the warning to see the family description).

When the first user uses Reload Latest or SwC they'll both be able to see this in the Project Browser, listed beneath Detail Items.

Subtlety compounded with yet another subtlety...if the family is already defined in the project (Central File) but a new TYPE is loaded by more than one user then we end up with this situation in the Project Browser.

How do we avoid this situation?

As soon as we think we need to load a new family or type...STOP.

Who (on our team) is responsible for ensuring the content we need is available to us? There ISN'T any ONE person assigned to this? There should be. All new content should be requested, requests sent to or asked of this person. That person can delegate the task.

The goal is to avoid the situation where more than one user is loading the same new content.

Only ONE person needs to load the family(ies)/type(s) and then use SwC to make it available to everyone else on the team (they use Reload Latest). We are working on the same project after all.

To close and return to what inspired my post, Jason went on to write that they've abandoned using Detail Components in their details because of this issue. Tragic. They (the detail families) aren't the problem; Revit's worksharing behavior and user habits are. I hope he'll revisit that decision.

Preserving the Active Workset

The Active Workset is a user setting. We can each work using a different Active Workset.

However there is a circumstance where I can affect what the Active Workset is for others.

When I Synchronize with Central (SwC) my Active Workset will be the one any user that OPENS the project afterward will see. That is true until another user uses SwC. Then anyone who creates their local file after them will inherit their Active Workset...and around the bush we go.

It's important to remember to check the Active Workset as soon as your Local File opens.

Keep in mind that other users that are already working in the file will not see a change, their own preference will remain the same. It affects anyone who creates their local file later.

We can agree as a team to always use SwC with a specific Active Workset in play. I can't really expect that to happen every time if I have difficulty remembering to set the Active Workset correctly for my own purposes. I just try hard to remember to check the Active Workset setting before creating any new elements AND especially as soon as I get my Local File open.

We can also remember to take advantage of the Gray Inactive Worksets feature (see image above) to help make it more obvious that we aren't using the correct Active Workset.

Worksharing Monitor is Dead - Long Live Worksharing Monitor

Well it took a LONG time but Autodesk has finally made the Worksharing Monitor application available for Revit 2016. I was thinking that it being missing was a test of our commitment to it. "Will they really miss it? Do they use it?"

Well I missed it and appreciate it coming back to life.

Long live Worksharing Monitor...at least until it truly isn't needed anymore...

Worksets for the Small Project

It is not uncommon to hear that people who are able to work on projects alone choose to ignore using worksets. Choosing to avoid adding any unnecessary complexity to the experience is one reason I hear. Another is, "Worksets are only required (and therefore useful) when people have to work on the same model together at the same time." It's true, I have written as much.

If this person is you, there are a couple of subtle benefits you might want to consider.

1. Opening inter-linked files in the same session
2. Selectively loading worksets while opening the file

Regarding #1 - It is not uncommon to work on projects alone and have multiple buildings involved. Revit does not like it when we choose to open a file that is already linked and loaded in a model we already have open. We get the message that the file needs to be unloaded first.

One way around this is to open more than one session of Revit. Each Revit session uses a separate Windows Clipboard, in memory set aside for each session of Revit. That makes it harder to use Copy/Paste to pass things back and forth if necessary.

If we use Worksets instead we are working in a Local File. We link files based on the central file though. The consequence of this is that we can open any number of other linked files in the same session of Revit now because we'll be opening a Local File, not the Central File. Revit doesn't object to that condition. NICE! It's enough reason for me to enable Worksets on every project, at least every one that will be involved in linking with other RVT files.

Regarding #2 - Choosing which worksets to open when we open a project is quite helpful because we can be creative with worksets and linked files and find ourselves able to choose which linked files should be opened too. Otherwise we have to wait until the file opens and then use Manage Links to Unload them or frequently use Visibility/Graphics to turn them on/off as required.

The trick is to create a unique Workset for each linked file we'll be using. Then we can choose which one to open when we open the project itself, demand loading of linked files via Worksets...since we can't manage links until the file is fully opened and all links are loaded. It starts here when you open a project (see image below).

When Revit begins to open the project the first thing it will load is the Worksets dialog which will give us a chance to decide which of them should be opened or closed. Anyone who has worked on projects with several (or many) large linked files knows how each file increases the initial opening time required for a project. Why put up with that at all?

Have I convinced you to give it a try? I hope so!

Withdraw your Editing Requests

In the past I wrote about how you can become the unwitting or accidental borrower of elements when you create an Editing Request but then close your local file before the request is resolved.

Therefore it is a good habit to Retract (withdraw) any Editing Requests you create before closing your Local file. If you form a habit of creating Editing Requests then also form the habit of Retracting any that are still pending when you leave for the project for any reason.

This is not a request...

Upgrade Projects from 2015 C4R to 2016 C4R

The Revit Clinic offered a post describing the steps to move a project from 2015 to 2016 versions of Collaboration for Revit. It isn't as straight forward as we might think. It isn't as simple as opening a 2015 project via A360 with 2016 and waiting for it to be upgraded to 2016.

Take these steps:

• Open Revit 2015 (with C4R installed)
• Browse to the A360 project that you want to upgrade
• Open each Revit model and save it to your local workstation
• Create a new project to be used with A360 Collaboration for Revit 2016 in your A360 team hub
• Open Revit 2016 (need C4R installed for 2016 first of course)
• Open each Revit model that you saved to your local workstation save it after it upgrades to 2016
• Initiate Collaboration on each model and specify the 2016 project name that was created on A360 earlier
• The model is associated with the new A360 Collaboration for Revit 2016 project
• Re-link any Revit models as required
• Let everyone know that they should use the 2016 project now

There are now two separate and distinct projects (2015 format and 2016 format). Everyone must use the upgraded (2016) project and models now. Remember to rename the 2015 version of the project or deactivate it via A360.

Be Careful Creating a Central File in 2015

A thread at Autodesk's Revit User Community Forum caught my attention yesterday. It seemed as though the culprit was something I've written about before, that user's were accessing the project via different shared resource paths. After digging in a bit deeper it turns out the issue, or at least an issue, is that Revit 2015 is more sensitive to how we navigate to the a shared resource.

This is what happens when I browse to a shared folder via My Computer and click on the Drive letter S:

This is what I expected to see (disregard the project name, I was experimenting with being logged in and out of A360 too):

A clue or warning you can watch for is what Revit displays at the top of the Save As dialog.

If you see the drive letter in the description then you'll likely end up with that as your path. I believe you should only see the folder the central file will be in if you are mapped correctly.

It is my habit to always use Synchronize and Modify Settings before closing the Central File, after creating it. As such I can see what the path that Revit captured is. When I notice that it is wrong, like the first image above, I can fix it, get the correct UNC path recognized instead by taking these steps (see the image that follows too):

• Close the Central File (after noticing the wrong path reference)
• Create a local file (before any other users start to work)
• Use Synchronize with Central
• Click Browse and click Browse again in the next dialog box that opens
• Select the Central File by browsing to it via the shared resource path instead, type it in directly if necessary.
• Click Open
• Click OK (the correct UNC path should appear now)
• Click OK (The path is fixed)

If you are creating a central file be very careful about how you browse to the project folder. Verify you have the correct path established before letting users begin working on the project.

Synchronization and Disconnected Systems

This is a bit idiosyncratic but if it helps sort out an issue then its worthwhile to echo it (based on a discussion at the Autodesks NG).

Imagine this scenario:

• An Air Terminal has an 8' elevation. A Duct rises from the Air Terminal to a elevation of 10'-0" and connects to a horizontal run (also at 10'-0" elevation), running parallel to the ceiling.
• User 1 raises the Air Terminal to an 9'-0" elevation. The vertical piece of duct connected to it changes in length, but no user is recognized as Edited by (owning/borrowing) for that element.
• User 2 decides to lower the horizontal duct (at 10'-0") to 9'-0". It is necessary for Revit to change the connected vertical Duct between the Air Terminal and the Duct to do so.

There are no warnings or alerts as these users do this. If a user decides to modify the series of elements, then a warning appears. A warning appears during Synchronize with Central only if this additional attempt to modify the element is made.

At the beginning I wrote idiosyncratic because it is easy to avoid if we agree not to work on each others elements. I would not ordinarily expect another user to decide to lower a duct that is connected to elements that I'm already working on. If we don't discuss what areas in the model we are focused on then it can easily happen. It is important to be aware of what others are working on. The Worksharing Display features can help us see what others are currently working on, if you don't really want to talk to your co-workers...but it's still a good idea.

Regarding the workflow above and not getting an error message, an Autodesk support person replied that they find an error message appears earlier to warn of the inconsistency when trying to reproduce the situation in the latest development build that will become Revit 2016. That means it is pretty likely Revit 2016 will prevent a duct element from being altered by two separate users when they interact with different elements that are both connected to it.

Username and Local Files

Revit knows who we are based on a simple piece of data, the Username entry here (Application Menu (Big R) > Options). That is usually defined by who logs on the computer. If we log on our computer, then open Revit AND change the Username...Revit preserves this alternate username until we change it again. If we never change this value then Revit just uses the computer's log on username identity. When we change it Revit captures and preserves it for this particular person's log on credentials on the computer.

Using Worksets (Worksharing) this username provides our unique identity to Revit, the Librarian (not to be confused with the TV show or movies). We can't just arbitrarily change our username while we are working in our Local File. If we do that we'll be greeted with an unpleasant message when we attempt to use Synchronize with Central.

We can become convinced that changing the username is permissible because Revit doesn't complain until we attempt to use Synchronize with Central. It's also easy to think it is reasonable because when the file contains changes that have not been synchronized yet we see this message when we attempt to change the username. When Revit complains and offers the reason that changing the name isn't going to work it implies that there might be an acceptable circumstance.

Fwiw, we CAN change our username freely if we are working in a central file (discouraged). However we won't find that very fulfilling if other users are also working on the project via their own local files. We'll be advised by Revit that it is necessary to use Save As to create a our own Local File first, when we use Synchronize with Central.

We CAN assume any username identity, we just have to change the Username parameter before creating a new Local File.

Damn Revit's Worksets and Worksharing features are fussy!

Specify Worksets and Save

We can preset the preference to use the Specify option when we open a project that has enabled Worksets. This option appears when we click the small arrow next to Open in the Open Dialog, which only works when we select a file with Worksets enabled.

This preference is controlled by a parameter called Open Workset default. It is only available to us within the Save As dialog, via the Options... button.

There is a subtle difference between enabling worksets in a file that has not been saved yet and one that has. If we enable worksets in a project that has already been saved, at least once before, we won't get a chance to change the setting if we just click Save. However if we use Save As we get the dialog that offers us the Options... button. The setting Open Workset default is not enabled unless the file is already using worksets.

This means it probably easiest to ensure that Specify is selected if we start a project and enable worksets before saving the file the first time. That might be easier said than done. If the file is already in progress and we need to enable Worksets we just need to use Save As instead, reusing the original file name if necessary.

Worksharing and Windows Operating Systems

Subtle bit of information shared via AUGI thread and member Meng005.

Autodesk response regarding a query asking about mixing version of Windows (64 bit and 32 bit):

When accessing workshared files from a shared Windows directory not utilizing Revit Server, it is important that all clients are using the same version of Windows, and thus the same version of SMB (Server Message Block). This is not the case when saving to Revit Server as the communication to the server does not use SMB. The client version of Windows, either Windows 7 or 8, is not critical when Revit Server is used.

It's fairly common knowledge that we should be careful to make sure that all Revit users (at a minimum that are contributing to the same Revit project files) have the same Revit build installed. Less obvious or common is the tip that they should also be using the same version of Windows!

Thanks for sharing Meng005!