How to change the installation path for 1Password 6? [Unsupported]

edited October 2017 in Windows

Hi,

I recently reinstalled Windows on some of the office computers and now when I try to reinstall 1Password on those computers it is trying to install to 'USERNAME.DOMAINNAME' and complaining that it can't create that directory, even though the existing user profile folder is just 'USERNAME'. Unfortunately, I can't change it because the installation is automated.

Is there any way I can correct this problem? I have roaming profiles set up, so being able to install to those would be ideal in many ways.

Thanks,
Joe


1Password Version: 6
Extension Version: Not Provided
OS Version: Windows 10
Sync Type: Not Provided

Comments

  • @FloodlightMedia: That's an oddball. Could you let us know what happens when you enter %LOCALAPPDATA% into Run dialogue? Also, is this issue pervasive across all machines you're attempting to install 1Password 6 on? Thanks! :+1:

  • %LOCALAPPDATA% takes me to the correct folder.

    The issue seems to be limited to specific users and follows them over multiple computers.

    These users would have had their profile in the username.domainname format prior to reinstalling Windows, owing to the relatively recent transition from local profiles to roaming profiles.

    But as I say, localappdata isn't really a useful place for me to install to anyway. It means 1password has to be installed for every single user on every single computer. So is there any way to override that install location with a custom one? This is pretty much the first program I've seen that doesn't ask me where I want to install it to.

    Thanks

  • brentybrenty

    Team Member

    @FloodlightMedia: Aha. Good catch! That makes sense. I've had similar issues when migrating my profile (the joys of software testing!)

    While you can use Innosetup command line parameters to do this, custom installation paths are not supported. It's possible that you could do it, but it may break browser integration, updates, and possibly other things. 1Password's installer will request admin rights, but you can select "no" to proceed without them (they are only needed for diagnostic purposes).

    The default, supported installation location is %LOCALAPPDATA%\1Password\, and since that is something other apps and services will use too, I'd encourage you to consider creating a new user profile so you don't continue to run into issues going forward. Even if you're able to work around this with 1Password, this is just a band-aid as it's really a deeper issue that needs to be addressed.

  • Righto. Well, at this point it's worth me giving Innosetup a shot. If a custom path does give me problems I shouldn't be any worse off than I currently am. I may even be able to try some sort of folder redirection so that it thinks it's installing in the default directory while still being stored in roaming profiles.

    Cheers

  • brentybrenty

    Team Member

    Haha I didn't want to say as much, but that's a fair assessment. I would encourage you to do a "test run" with a throwaway account just to be on the safe side if you're going to go the extra step of trying to "redirect" the file access, since 1Password does need the database to be available at all times; if it isn't it could result in data loss, so we always use a local folder. Better safe than sorry. :)

  • But roaming profiles are still local though, surely? They're just synced at logon and logoff. Unless I'm missing something, I'd probably still be putting my hand up for custom installation directories in some form as a feature request.

    At any rate, it looks like setting up a symbolic link is the best way to go for people looking to shift the program to a roaming profile.

    I created a batch file with:
    mkdir -p %appdata%\1password
    mklink /j %localappdata%\1password %appdata%\1password

    Then set the batch file as the user logon script. 1Password installed fine and then worked from another computer without a hitch.

    The only catch is that that it can't create the symbolic link if they have already tried installing 1Password on that computer. I'll either have to do that manually, or just make it delete any existing folder there before creating the symbolic link. Getting a bit late today though.

  • @FloodlightMedia: We've actually used symlinks to workaround at least one issue ourselves with roots in a Chrome bug. I'm not going to go so far as to say it'll all work swimmingly, but if you know what you're getting yourself into and are okay with the risks, I'll be interested to hear how things go. :chuffed:

  • brentybrenty

    Team Member

    @FloodlightMedia: Sorry for not being clearer. As I'm sure you'll understand, I wanted to offer some caution since others may read this forum discussion as well. The only time you should run into issues with that is if you're symlinking to a network volume. I just know that others have tried to do this, even if it's not your goal in this case. Better safe than sorry. ;)

  • edited October 2017

    [Warning by AgileBits: Note this user-provided instruction is not supported nor recommended by AgileBits, it can result into a total wipeout of 1Password data if not done correctly. We cannot be held responsible if you proceed to use this instruction].

    Ah, I see. Yes, running from a server could definitely have appeal, but in this case a local copy is quite preferable, so all good.

    For the benefit of any other advanced users who may be looking for a similar solution to me, here's my entire batch file code with notes as it stands (no warranties or guarantees provided :p ):

    rmdir %localappdata%\1password /q /s
    

    Without asking for confirmation this deletes any existing 1Password folder and files (or symlink) in the Local profile folder for that user. Should only be used if people have already installed it on some computers and you're satisfied their data is safely backed up. It may be beneficial to eventually remove this line, since it's rather powerful.

    mkdir -p %appdata%\1password
    

    Creates an empty 1Password folder in the Roaming Profile directory. Can be changed to whatever directory you prefer, but as mentioned by staff above, it should be on the same computer to minimise problems.

    mklink /j %localappdata%\1password %appdata%\1password
    

    Creates a symbolic link where 1Password would usually install, seamlessly directing it to the new directory.

    If Not Exist "%USERPROFILE%\Desktop\1Password 6.lnk" copy "\\<_servername_>\<_sharename_>\1Password 6.lnk" "%USERPROFILE%\Desktop"
    

    Makes a copy of a pre-existing shortcut and puts it on their desktop, since the lack of a proper installation may make it hard to access otherwise. Just be sure to use variables like %USERPROFILE%\Desktop in the properties of the shortcut so that it works for all users.

    Cheers,
    Joe

  • bundtkatebundtkate

    Team Member

    Thanks for sharing @FloodlightMedia! :+1: :chuffed:

  • One potential problem I've discovered with this method is that the Firefox extension doesn't seem to detect the installation.

    Chrome seems perfectly happy with it though, so it may be a separate issue.

  • bundtkatebundtkate

    Team Member

    @FloodlightMedia: Could you share some details about the Firefox extension's problem? Does it throw any sort of error or is it just not properly displaying your data from the main app? Ultimately, it would be good for us to find a workaround here as we definitely want y'all to have your choice of browsers to use. :chuffed:

  • edited October 2017

    The extension just flat out never does anything. It just sits there greyed out, and nothing happens if you click on it. It probably has to do with copying files to roaming profile folders rather than going through the proper installation for every person and computer. That said, it is strange (and great) that the Chrome extension happily detects the main program as soon as you open it.

    As much as I prefer Firefox, the office in general overwhelmingly uses Chrome, so it's not a huge problem for us. I'll probably do proper testing at a later date. I just thought I'd mention it as a quick warning in case anyone else goes down this road.

    (Firefox is obviously going through a lot of big changes atm, for better or worse, so that may also be relevant)

  • MikeTMikeT Agile Samurai

    Team Member
    edited October 2017

    Hi @FloodlightMedia,

    That could be because of the registry paths for the Native Messaging support, both Firefox and Chrome uses the path stored in the registry to load the manifests stored in 1Password directory to launch the right process.

    If you run /setup after installing 1Password, it should add the proper registry paths or if you want to manually script it:

    Firefox:

    [HKEY_CURRENT_USER\Software\Mozilla\NativeMessagingHosts\2bua8c4s2c.com.agilebits.1password] @="C:\\Users\\miket\\AppData\\Local\\1Password\\app\\6\\FirefoxManifest.json"

    ^ note the path, customize it to the user name but it must be full entry, no environment paths accepted.

    Chrome:

    [HKEY_CURRENT_USER\Software\Google\Chrome\NativeMessagingHosts\2bua8c4s2c.com.agilebits.1password] @="C:\\Users\\miket\\AppData\\Local\\1Password\\app\\6\\ChromeManifest.json"

  • MikeTMikeT Agile Samurai

    Team Member

    One more thing, I edited one of your posts to add a warning that the included instructions is not supported by us and can result into data loss if it is not done correctly.

  • @MikeT Thanks for that registry info. After the latest major update the extension stopped working in Chrome as well and was constantly throwing errors.

    I created a GPO to update the above registry entries, with a resolvable variable for the usernames (ie %LogonUser% ). It fixed everything almost instantly for multiple usernames, and should hopefully continue to do so until the next major version. And even that should just require a quick edit.

  • brentybrenty

    Team Member

    Thanks for the update! I'm glad to hear that did the trick for you. Thanks for sharing. :)

  • Ok, I have encountered a strange issue. The registry entry seems to randomly get reverted from time to time while somebody is using their computer. My first guess was that the software was updating and overwriting the registry entry in the process. However, this seemed less likely when it happened to me multiple times in the same day.

    Would 1Password be responsible for changing it?

  • brentybrenty

    Team Member

    @FloodlightMedia: Indeed, while I'm not sure what you mean by "while somebody is using their computer", 1Password definitely doesn't update itself multiple times per day. We can't even release updates that fast on the beta channel. However, as mentioned previously this isn't a setup we support or test for, so your guess would be better than mine with regard to the cause.

  • Oh, I just meant that the registry was changing while the computer was in use, as opposed to user logon or the computer being turned on.

    That's alright. My fix gets applied with every user logon, so it's not a big deal. I'll keep experimenting. Thanks.

  • brentybrenty

    Team Member

    Ah, gotcha. That's a bit odd, but it sounds like you have it well in hand. Cheers! :)

  • Ok, I've worked out the problem. If 1Password launches via the normal executable (including via Windows Startup), it automatically resets the registry entry for all browsers. Presumably this is a safety feature to prevent misconfigurations, and even allow a copied directory to work without a formal install. Unfortunately, the only GPO counter I can think of would be to lock the registry keys.

    However, if somebody opens their browser first and the plugin launches 1Password instead, it works fine. I may just have to train the staff to do that instead, after disabling 1Password in their Startup.

    I would still strongly like to add custom installation directories (or at least the option of Roaming instead of Local) to any feature wishlist that might exist though. I don't know what the advantages to the Local directory are meant to be, but I can honestly say that this program excels in a roaming environment. This one drawback aside, it's quite well made.

    Cheers,

    Joe

  • brentybrenty

    Team Member

    @FloodlightMedia: Thank you for the kind words, and your feedback on this. We'll continue to improve these processes, and perhaps in the future we'll be able to offer a supported means of deployment. I'm glad that this workaround does the trick for you in the mean time. :)

  • MikeTMikeT Agile Samurai

    Team Member

    Hi @FloodlightMedia,

    I just want to let you know that we do have an unintentional side effect in the recent 1Password 7 update where it is updating the registry to include the default directory (not from the 1Password directory) at every 1Password start.

    This will be fixed in a future update and we do have plans as Brenty mentioned to support company-wide deployments/management. We started to add more Group Policy support as well that we'll document in the near future.

    ref: OPW-2324

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Emoji
Image
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file