Issues with multiple Windows accounts
Author: ReduxedPollux
Creation Date: 9/11/2018 7:33 PM
profile picture

ReduxedPollux

#1
Was doing some work on 2nd user acc and when I went back to user acc 1 sever strategies were not listed. I have mapped them to appdata and they are working at this point. But is this the best way to do this? Does wlp not store these changes where the .exe is located?

A few months ago, wlp suddely stopped allowing me to run as admin so I promptly got paranoid and did a clean install of win8.1, reinstalled wlp.... same issue. Changed compat settings to always runas, can't rt click run as, can't run as admin from cmd as admin, can't run from task manager as admin, Same uac issue on all. User 1 acc dl'd, installed, and has full permissions. Win8.1 so no group policy editor. Have not edited registry yet... Eventually created a 2nd user (from user 1 acc), bam, no troubles, doesn't even prompt for admin pw just instantly opens. The only way I've found to open it on user 1 acc, is to create a short cut on user 2 acc desktop using runas /user\admin /savedcred and can run it on user 1 acc by navigating user/user2/desktop/wlp.exe. It does flash a cmd I assume is entering the admin pw. This is the only program I've ever had this issue with. While this is a solution, this doesn't seem like a solved problem. Does anyone know of THE solution? If it's regedit I'm fine with that, or something so simple it's embarrassing I overlooked/haven't found it, I could use a cheat code.

Also are these 2 issues related? Seems like it could be, but doesn't have to be.

Sorry for such a long txt, any advice would be much appreciated.
profile picture

Eugene

#2
This mess is probably a good counterexample for anyone to not run into. Could you start with what's your objective in using WLP? There must be a reason behind shooting oneself in the foot with multiple accounts and the unsupported symlink (mapping) hack. Finding it may help cut this Gordian knot.
profile picture

ReduxedPollux

#3
Sorry didn't mean to post it in dev, it was just where I happened to be looking when I decided to post. The main objective would be to tweak and customize existing strategies, and code some custom ideas. My account isn't at fidelity's size requirement for automation, but I can dream right? Not really looking to get deep into dev type stuff since my exp is limited in .net. Plus dev seems kinda out of the picture considering the current circumstance.

I misspoke in prev post, user2 may have been prompted for admin pw on 1st run but def hasn't ever since. user1 was never prompted in any attempted method for creds. Considering the only way to get it to run a cmd flashes, it seems that cmd is giving creds, and the issue is the lack of a prompt when attempting? I don't know, I'll post back if solution is found.
profile picture

superticker

#4
QUOTE:
The main objective would be to tweak and customize existing strategies, and code some custom ideas.
I do that sort of thing all the time from one "User" account on Windows 7 (Windows 8 would be the same way.). I rarely run any Windows application in the administrator account; there's a major security concern if you do and the app you're running is malicious. The only time I run Wealth-Lab in the administrator account is when I'm using Extension Manager to install stuff. Even my Visual Studio DLL library development for Wealth-Lab is run in a standard User account. (There's a special exception when you "first create" your DLL library where you need administrator rights to initially get it into Wealth-Lab's program directory, but as "Creator" you have full access to your DLL library after that from your Windows User account.)

Wealth-Lab doesn't really use the Windows registry for much, so you don't need to reinstall it for registry issues. It saves all it's configurations in the AppData directory for a given User account. And I manage all this with a single Wealth-Lab login on a single Windows User account.

QUOTE:
My account isn't at Fidelity's size requirement for automation
Separate issue, but Wealth-Lab excels in managing individual stocks, and you need enough capital to hold about 30+ positions (of stocks) so you spread your risk appropriately. I guess you could hold really small positions and still do that, but is it worth it? You could invest in penny stocks, but I'm not so sure standard technical analysis (Wealth-Lab) works well with penny stocks.

I wouldn't use Wealth-Lab for managing mutual funds. If you're a numerical analysis nerd, I would employ Modern Portfolio Theory (MPT) methods to manage those. R has some packages for doing that with Efficient Frontier and Smart Beta (to name some MPT methods). Fidelitiy's own fund managers use Efficient Frontier for many of their mutual funds with the goal of reducing turnover within them while optimizing gains. All MPT methods are solving a time-independent optimization problem.
profile picture

Eugene

#5
@ReduxedPollux

John, if you have no special reason for the multiple account fuss (as it seems from your answer) then it makes sense to not do what you've been doing. The only good reason to continue running as admin is VS extension development. This requires admin rights every time you overwrite a DLL in Program Files i.e. rebuild a compiled Strategy library. If so, simply log in to the the admin account and run WLP there. Of course you'd have to set UAC to the maximum level for system's safety.

P.S. Note that WL hardly can "stop you from allowing to run as admin" - this must be some misconfiguration of your Windows.
profile picture

superticker

#6
QUOTE:
The only good reason to continue running as admin is VS extension development. This requires admin rights every time you overwrite a DLL in Program Files i.e. rebuild a compiled Strategy library.
I use the Visual Studio IDE (VS) from my Windows User account exclusively. As I said above (in parentheses), there is an issue when you first create your DLL library where you need administrator rights to move it into Weath-Lab's program directory. When doing so, you should retain ownership of your own DLL library because the Creator/Owner has full file access rights--including Modify rights--to his own files in the protected Program Files hierarchy. As a result, you can run VS in your own Windows User account for all subsequent builds. (NOTE: By performing a file "move" into Wealth-Lab's directory instead of a copy, as administrator, you should retain ownership of your own files automatically. If your already performed a "copy" so administrators are the owner, then you'll have to change ownership back to yourself on your copied DLL files.)

It is unwise (from a security standpoint) to run any IDE (VS included) from the administrator account. Now there are situations where VS's execution profiler (Are you using that?) may require more system privileges than the standard Windows User account. If you're running Windows Ultimate, grant those rights to the Power Users group (or create a special Windows Developers group for this), then promote your User account to a Power User. Now you can even do profiling from your Windows Power User account. But for typical VS development, you can just run VS from a standard User account; I do it all the time when I'm not using the profiler.
profile picture

ReduxedPollux

#7
Found some files and folders left over from previous attempts to solve with uninstall/reinstall. Uninstalled, deleted every file/folder that I could find and reinstalled issue resolved.
profile picture

Eugene

#8
Good news!
profile picture

Eugene

#9
QUOTE:
NOTE: By performing a file "move" into Wealth-Lab's directory instead of a copy, as administrator, you should retain ownership of your own files automatically

That's true. However...
QUOTE:
It is unwise (from a security standpoint) to run any IDE (VS included) from the administrator account.

...it's this (run IDE from admin account) that lets one start WLP/D from his VS solution conveniently by hitting F5 instead of having to Build, then start WLP/D, then Attach to Process for an interactive debug session.
profile picture

superticker

#10
QUOTE:
[running the] IDE from admin account ... lets one start WLP/D from his VS solution conveniently by hitting F5 instead of having to Build, then start WLP/D, then Attach to Process.
I use the latter process rather than the F5 key. And I don't need to typically Attach to Process unless I'm debugging my library. Typically, I try to debug my routines/classes in the main strategy before placing them in my DLL library. But the VS symbolic debugger is amazing (it inspects inside object trees) and time saving.

UPDATE: Well, it appears *if* you want to run the VS debugger in "some unusual situations" (see link below), the simplest solution is to "configure the VS IDE project manifest" to run VS as administrator. That can still be done from a standard Windows account so only the VS IDE (and its debugger) have elevated permissions; all other apps run with standard permissions. I would try debugging with standard permissions first before promoting the project manifest to run VS as administrator; I only needed elevated permissions when running the execution profiler, not the debugger. https://docs.microsoft.com/en-us/visualstudio/ide/user-permissions-and-visual-studio

Thanks for the tip about the F5 key shortcut. I'll have to try that.
This website uses cookies to improve your experience. We'll assume you're ok with that, but you can opt-out if you wish (Read more).