Sorry to have to post this, but I've had a problem hiding a Kaseya created User profile on my customers machines.
Obviously it concerned a lot of them when this mystery user showed up.
Despite telling them its there, they find it disconcerting........ so the best option is to hide it via script
Yes, its a newbie problem, so i'd expect a quick response
There are LOADS of suitable scripts available which purport to do the job.
They don't work for me, so I turned to Support.
At the (good) suggestion of my teacher, I created a dedicated user profile on my customers machines. (win 10)
Obviously I'm getting lots of concerned calls wondering who this "OCS-Admin" user is.
I've tried existing scripts, but they don't work I've explored existing scripts in order to hide this profile.
Q. Do you have a suitable script available to.... 1. Create this user if not present 2. Then hide it.
Thanks in anticipation."
I did get a reply on the 15th, which was well-meaning, but effectively worthless.
15th DecemberHi Maximo
Thanks for the reply.
When you create a user with "REMOTE CONTROL/DESKTOP CONTROL/RESET PASSWORD", (ie OCS-Admin) it fails to create a key within HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList
That's the problem.
If I manually create that key, (HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList\OCS-Admin) the user gets hidden.
Efforts to create that key via scripting, fail.
I'm aware of setregistryvalue() and Set64bitregistryvalue(). Not working.
Efforts to use REG ADD also dont work.
Most of my customers are win10 home 64bit users.
Sorry (again). This issue is still unresolved. Also getting FAILS when I try to create some admin users. see attachment.
Are you having generic scripting issues ?
Hello ? Anybody there ?
Still got a problem here. Support not looking brilliant from my point of view :(
My Support Guy.
I contacted him, but there has been no movement.
I contacted him again. No response.
I appreciate the time of year, but waiting best part of a month for what (to me) should be a simple common fix, with no responce to repeated requests for help, is not on.
Interesting - I created a support request about 2 weeks ago. Within 40 minutes, the engineer had logged onto the VSA, identified the issue, and responded with the action to take. Following his direction, the problem was solved in the 3 minutes it took to run a SQL update query.
What's the difference? I provided specifics - error message or condition; remediation actions attempted and their result; details about the situation.
I imagine that when tickets are reviewed as they are received, they are evaluated and assigned based on criticality, then potential ease of resolution. Providing more and detailed information up front will usually make the issue easier to understand, and improve chances of a quick fix. Be vague and the low priority tickets go to the bottom of the heap. It's not policy, I'm sure, just human nature.
Think about the possible conversation when you visit the doctor and say "my knee hurts" instead of "my knee hurts when I spend the afternoon weeding the garden after playing in the morning soccer match". :) Poking and berating the tech - in the ticket or public forums - doesn't help the situation, either.
I have a procedure that hides our "RMM_Admin" account from the Windows logon, setting the registry key based on the O/S 32/64 bit version. You can download a copy of "Procedure Hide RMM_Admin User Account.xml" from the MSP Builder web site. Import it, rename the account name and give it a try.
Still no joy.
I've just visited a customer.
The user OCS-Admin had successfully been created via the VSA system BUT
I had to run regedit and manually add the keys "SpecialAccounts\UserList" and set the DWORD value (OCS-Admin) to 0
This hid the user I wanted.
VSA doesn't create the registry keys I need.
Scripting doesn't work creating this value either.
Looks like I will have to perform this manually on ALL my customers machines.
For the record, I did supply a proper breakdown of the problem , with screenshots.
I've participated in a number of forums over the years, and am well aware of the "newbie post" syndrome.
Firstly, The Kaseya help doesn't say anything about it being capable of creating hidden accounts - I think you're possibly expecting functionality that doesn't exist.
The correct answer is to set the registry keys as per www.windowscentral.com/how-hide-specific-user-accounts-sign-screen-windows-10 and it sounds like this is what you're trying to achieve, and using a agent procedure(script) to create the registry entries, is the best way to do this.
Obviously there's an issue with your registry-setting script. Can you post your script here so we can help you debug it? Have you looked into the script - does it run without error? what errors are logged in the script log (if any)? Does your REG ADD command work if you run it directly from the desktop?
One thing you might be stumbling on - if a registry KEY doesn't exist, you need to create it before trying to store any entries in it (a good parallel would be that you have to make a folder before you can put files in it - supplying a nonexistent path in the 'save as' dialog won't create the folder).
Many scripts won't work if you haven't set a valid AGENT CREDENTIAL (and the step is set to 'execute as system') - have you done so? If the step is set to 'execute as user' it will only work if someone is logged on to the machine at the time the script is run.
Finally, In the same way that the vendor of any programming language won't assist you to learn to write software, so Kaseya really can't help individuals write scripts. If you find a bug in the scripting engine, then Kaseya support is certainly the place to turn to, but support isn't the place to go when your script just isn't working the way you want it to, and you need some debugging assistance.
Fortunately, these forums assist and there are helpful folks here who can lend a hand ...as I said, post your script & the related logs, and we can try to help you from there.
First off, Thanks for taking the time to reply Craig.
I've been on your side of the forum discussion too many times :), and I appreciate you are trying to help.
Win 10 Home (64 bit)
I have "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\"
All well and good.
"SpecialAccounts\UserList" is missing.
1. I want to create the KEY "SpecialAccounts"
2. Within "SpecialAccounts", I want to create the KEY "UserList"
3. Within "UserList", I want to create the DWORD "OCS-Admin", with the default value "0"
Q. Is there a simple script to perform actions 1, 2 and 3 please ?
Please see a "Before" and a requested "After".
Bertie40 , Kaseya support was closed Friday and Monday. I would say that your request really doesn't fall under their normal support. You are asking them to write/debug a script for you, which is not something that they typically do. This kind of request is best handled by the community. Craig Hart, was on track that the function to create a local user, does not create a Hidden user (maybe a nice feature request!). That being said, there is much you can do to improve your odds of getting a quick answer from the community.
1) Publish the actual agent procedure logs errors
2) Publish your script.
3) List debugging steps you have taken
You say that none of the scripts that are published seem to work. That might be red flag, this process hasn't changed in many years, so if it has worked for others, it should work for you. Occasionally some of the internal Kaseya script functions fail to execute after an update. If that is the case, you will see this in the procedure log files, and it is a fairly easy fix with support.
You might also try an admin name without the "-"(dash).
Please publish your script and logs so we can help. Happy New Year!
I would suggest trying to go round this the non-technical way.
If you require a user account created for a task, make it public knowledge.
Don't get me wrong, if you need to do this covertly by all means hide it.
But sending coms out to the required people advising them what this account is used for should suffice, this is also a lot less work; a single email vs scripts and support etc.....
That's indeed what I've done to a number of my customers, but some of them are quite elderly, and don't like this "mysterious user", even though they know its me.
Also, my admin name interrupts the startup sequence, whereas a single user logs straight in.
I've made some progress, and discovered that Kaseya scripting CANNOT create registry keys........ but it can be conned into doing it.
Respect to LegacyPoster from 2009 !
My script (see below) works on my work machine, but doesn't work on other machines. I suspect because the keys "SpecialAccounts" and "UserList" already exist in some cases.
I've changed the switches from fail" to "Continue on fail", but i lack the scripting knowledge regarding error detection,.... or am i missing something again.