Forum Discussion

AL_G's avatar
AL_G
Level 4
15 years ago
Solved

"Cannot expand the folder. The set of folders cannot be opened" happening on machine rebuild

Hello

We're rebuilding quite a lot of machines at the moment.

The mahcine are being rebuilt with the same name, the same OS version (Windows 7) and the same version of Outlook (Outlook 2010)

In almost all cases that I've seen so far, when the users login and launch outlook, they see a their virtual vault, but when they click on it, they get a message like the one below:

"Cannot expand the folder. The set of folders cannot be opened. The file C:\users\username\AppData\Local\KVS\Enterprise Vault\<number>\<numer>p-in-arc-01.mdc cannot be found"

NOTE: when checked, .mdc file is present in the location listed.

In some cases it just "started working" later on.
In some cases it never starts working again.
We have tried doing a manual "Reset" and this seems to provide a "workaround".

Questions:
- What is the expected behaviour if a machine is rebuilt with the same name?
IMHO it should "just work" i.e. there should be no need to manual intervension / workarounds being applied.
- How can we "fix" this? (it's not really a feasable option to have to select "reset" for each individual users after logon !!!)
- We're rebuilding quite a lot more machines and need a "resolution" rather than the workarounds currently being used.

We're using the latest vault client (released in February this year)

Thanks
-AL

Enterprise Vault
Information Governance
  • JesusWept3's avatar
    JesusWept3
    15 years ago

    Well if the machines are being rebuilt, then the Vault Cache shouldn't exist and the Vault Client should be rebuilding the Vault Cache itself. Are you perhaps exporting and then re-importing the registry keys and what not from the previous machine?

    The machine name isn't really what controls the Vault Cache, its the user that logs on and the Store ID in the users mailbox (Explained in the last post the Store ID  is gathered from the PR_STORE_RECORD_KEY in the users mailbox)

    If you are rebuilding a machine, would just suggest not trying to re-inforce the Vault Cache by copying the items or the registry hives across from the old machine and just let Enterprise Vault start building the vault cache from scratch

3 Replies

  • JesusWept3's avatar
    JesusWept3
    Level 6
    15 years ago

    Well if the machines are being rebuilt, then the Vault Cache shouldn't exist and the Vault Client should be rebuilding the Vault Cache itself. Are you perhaps exporting and then re-importing the registry keys and what not from the previous machine?

    The machine name isn't really what controls the Vault Cache, its the user that logs on and the Store ID in the users mailbox (Explained in the last post the Store ID  is gathered from the PR_STORE_RECORD_KEY in the users mailbox)

    If you are rebuilding a machine, would just suggest not trying to re-inforce the Vault Cache by copying the items or the registry hives across from the old machine and just let Enterprise Vault start building the vault cache from scratch

  • AL_G's avatar
    AL_G
    Level 4
    15 years ago

    Hello

    re: "the Vault Cache shouldn't exist and the Vault Client should be rebuilding the Vault Cache itself"

    > agree - thats what I would expect

    re: "Are you perhaps exporting and then re-importing the registry keys and what not from the previous machine?"
    > not as far as I know - can you elaborate on "which keys" ?
    Users do have roaming profiles (which is widespread "normal" practise) so I wouldnt expect to have to do anything about contents of HKCU.

    re: "Store ID"
    > good info thanks!

    re: "not trying to re-inforce the Vault Cache by copying the items or the registry hives across from the old machine and just let Enterprise Vault start building the vault cache from scratch"
    > AFAIK we're not "intentionally doing that. The only caveat being that we are using roaming profiles (but then that is widespread common practise and it has to work in this scenario). Since the actual file location it's reffering to is within AppData\Local, obviously that file itself is not roaming and I would absolutley "expect" it to be recreated fresh

    Thanks for replying - very usefull but not "quite" there in terms of a "resolution" yet.

    Best regards
    -AL

  • AL_G's avatar
    AL_G
    Level 4
    15 years ago

    I hadn't followed up on this for a while, but I ended up looking at this again today.

    I "think" I know the cause:

    If you have a user account with a roaming user profile, logon to a new machine, launch Outlook then click on the Virtual vault (Vault - <username> node), this error will appear.

    However - if you logon to a new machine without a roaming user profile, the behaviour is slightly different - Outlook dosn't immedialtey Virtual Vault node, instead this appears slightly later on and it then works fine.

    My "guess" is that it's taking a while for Vault to create the .MDC file....
    In a "roaming profile" scenario     (i.e. with registry keys relating to vault in HKCU), Outlook immediatley shows the VV node, giving the users the opportunity to click on it before the .mdc is created - thus giving an error.

    Does anyone else see this (surprised they dont as it's very easy for me to re-create)

    Thanks

    -AL