• Replies 19 replies
  • Subscribers 5475 subscribers
  • Views 33160 views
  • Users 0 members are here
Recent DeltaV Community Connect Discussions
Similar Posts
Domain/Local Accounts
DeltaV 15.3.1 (LTS) Workstation Configuration Error - Can't join Workgroup/Domain
How I can change a local user on a domain controller (Pro Plus)?
Changing to Domain control after the fact
Login options after workstation configuration (Domain)
Share

Local accounts after joining domain

I have installed DV and joined the domain on my Proplus. I'm not quite sure what to do with the Emerson and Administrator accounts now. The Administrator account gets disabled during installation. Emerson is just a local account. I did the complete install logging in with my domain admin credentials. What is the typical application?  When I first tried logging in after install.. I could log in with any account, but in order to get to windows desktop, i had to use the domain admin account. I don't know why the administrator (after enabling) or the Emerson account wouldn't work. 

In the past with workgroups we would primarily use Administrator for well, admins that could get to windows desktop and then a SUPER account that did not have admin privileges and would only be good for DeltaV logon.  

I'm not sure what best practices are with this setup. Oh, i have v15 on a R660 server 2022. I have 2 IDDCs. 

Thanks

TreyB

19 Replies

  • Edward S Goh
    Local accounts are useful when you need a backdoor into the servers or workstations. Best practice is to avoid any default accounts. Administrator will typically be disabled automatically when using a lot of Emerson automated setup scripts since it is a common default username. I usually create a unique local account via Computer Management and give it the local Administrator group. Then I login with that account and disable the local Emerson account. At the bare minimum, I would give the local Emerson account a strong password. The local Emerson account should be a member of the local Administrators group by default. Note that this is useful only for dealing with Windows OS stuff, not DeltaV.

    From a DeltaV perspective in a domain, almost everything should be logging in via domain users. User Manager will take care of the domain groups/permissions for you. There are specific situations where you may need to create local accounts, and you would use Computer Management on the specific servers or workstations to create those.
  • TreyB

    In reply to Edward S Goh:

    So the only administrator account on the domain should be the domain administrator? All other administrator accounts would be local? User Manager can still propagate those right? For instance i just finished adding a few workstations and my administrator account was disabled. So, I enabled it, set a password. Logged off.. tried to log on only to find out i don't have windows desktop access even though it's an administrator account on the machine. I'm not sure why it's restricted.
  • Edward S Goh

    In reply to TreyB:

    Local administrator accounts are not DeltaV accounts so that account will not be able to access DeltaV functions, such as accessing Windows Desktop via FlexLock. In a domain environment, what you see in User Manager are domain users, and you cannot add the local administrator accounts on each computer or server as DeltaV accounts. Once you are in a domain environment, all routine work is done with domain users usually. So I would be logging into Windows on the workstations with a domain user almost all the time once you have your local administrator account setup the way you want it. If your domain stops functioning (i.e. you are not able to login via domain credentials) then your local administrator account is the only way to get into the computer in front of you for disaster recovery.

    You can have multiple Windows Administrators (checkbox under Account Type in User Manager) for your domain. You could also separate the DeltaV Administrator account and the Windows Administrator accounts too if you want to follow the principle of least privilege. Do you want a single shared super admin account that can do anything on the system so you have less users to manage? Do you want every user to have their own login so that if they quit you just have to disable their account? User management needs a balance of maintainability and security and every site places a different weight on these things.
  • TreyB

    In reply to Edward S Goh:

    Roger that. I think i got it almost working. Just needed that philosophical check. I'm not the system admin, so in the end, i'll let them mange how they want.
  • TreyB

    In reply to Edward S Goh:

    I came across a problem yesterday that has me thinking. I had an issue where deltaV services wouldn't start. So, when it timed out it asked if i wanted to log into windows desktop with a local administrator account. I did so. However, then i couldn't run workstation configuration because I wasn't a domain admin. So, I was forced to basically wipe the machine. I was in a catch 22 where I couldn't log in as domain admin because services didn't start, and i couldn't run the likely fix to get services to start because i wasn't a domain admin. I was hoping there was a solution, but doesn't seem i can make my local account a domain admin. That's not even a group available on my local machine. It was "fine" now because this is a new system.. but that could be a catastrophic issue for a running plant. Is there anyway to allow a domain admin to log into windows desktop if services don't start.. or a way to make a local account a domain admin. Seems to be the only two options and both seem unlikely.
    Thanks
  • KeithStThomas

    In reply to TreyB:

    Are you able to access the windows desktop using the domain administrator? If so, try running regall/ register again.
  • TreyB

    In reply to KeithStThomas:

    idk what that command is in relation to running workstation config or starting services, but no. DeltaV will run through it's process trying to start the service. Once it can't start, it asks if you want to log into the windows desktop with a local administrator account. domain account login at that point is not an option. Which is why i can't run workstation config. I have to run it with an account that is part of Domain Admins.
  • KeithStThomas

    In reply to TreyB:

    regall /register is a wonder drug that can fix weird issues like what you are experiencing. What user did you log into windows with originally? If it is a domain admin, then you are still domain admin once you get to the windows desktop even if you had to use a different DeltaV user to switch from DeltaV Desktop to Windows Desktop.

    I've had cases like this in the past where it seems to be a locked box with the key stuck inside. Once I could reach the windows desktop, I would run regall /register from a cmd window, then run workstation config. This usually clears up the services issue without having to re-image the PC.
  • TreyB

    In reply to KeithStThomas:

    Well, i would have loved to try that. but i'm already wiping the thing. My recent comment was more to the point of how to prevent it in the future. I've not heard of that command before. I'll keep it in mind.

    In regards to the domain admin.. yes, it would seem that if i originally used the domain admin to login it should be good. But.. when i would run workstation config as domain admin (after switching from DV desktop to windows desktop), it would spin like it was starting and then do nothing. Maybe that is not typical and is symptomatic of the other issues i had. So, i had domain admin, which would just spin.. built-in administrator which can never run WC, and Emerson account, which is not and can't be a domain admin. I was 3 strikes.

    I have our impact partner getting me the recovery media for this particular server model we have since i originally used a generic OS installer.
  • Nick Mason

    In reply to TreyB:

    If you end up locked out of the windows desktop in the future, you can connect to the machines registry remotely (From another domain member) and change the AutoSwitchingEnabled DWORD to 0. This is the the same function as disabling Autoswitch Desktop. A preventative measure is to disable Autoswitch Desktop prior to running wks config.

    When setting up a new DeltaV Workstation node in a domain environment, I always name the computer and join the domain prior to running wks config. Haven’t ran into the lockout issue for several years using this method.

    Hope this helps.
  • TreyB

    In reply to KeithStThomas:

    Problem returns.. I hate Domains in DeltaV....

    This time.. I can't get to the Desktop at all. Any ideas i could do this time?
  • TreyB

    In reply to Nick Mason:

    do you know where in registry this would be located?
  • JoshC

    In reply to TreyB:

    It's at HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\FRSI\DeltaV\CurrentVersion. Change the value of AutoSwitchingEnabled to 0
  • TreyB

    In reply to JoshC:

    yeah, i used the FIND, of course. It was a dumb question. Regardless, i'm in an endless loop now and can't even reinstall deltaV. Domains are garbage in DeltaV.
  • Lun.Raznik

    In reply to TreyB:

    RE: This time.. I can't get to the Desktop at all. Any ideas i could do this time?

    I skim through the discussion but I can't find details, like:
    - What version of DeltaV are you using. Domain policies have been changed over time. Due to cyber security improvements, v15 is more locked down than v14.
    - Are you using IDDC?
    - If not IDDC, are you logging in to ProPLUS? Is ProPLUS a domain controller?
    - Is this supported physical machine? If not, what specifications do you have? Newer versions of DeltaV needs more RAM and faster CPU. Using old units will cause DeltaV not to start in time. You can workaround this but you need to know what you are doing.

    Also, are you able to login on another machine and look at Event Viewer remotely? If yes, I would check Application and System log. Look for anything Error (RED) and report back.

    Note domain can be good and be a headache. If you are using virtual machines, be careful with snapshots, it will make your life challenging. You also need to have working NTP, ensure workstations are fairly close in terms of time.


    Re-reading original post says you are using IDDC. 

This is the official online community site of the Emerson Exchange, a forum for the free exchange of non-proprietary information among the global user community of all Emerson's products and services. Our goal is to improve the efficiency and use of automation systems and solutions employed at members’ facilities by sharing our knowledge, experiences, and application information.

Community Guidelines | Legal Information | Privacy Policy | Contact Community Manager

Website translation provided by Website Translator

© 2015-2026 Emerson Exchange. All rights reserved.