Kaseya Community

Domain Accounts Created before 6.3 Update Cannot Login / Support Frustration

  • I am currently having a problem where VSA accounts that are linked with domain accounts cannot log in.  I have found that accounts that were created after my 6.3 update (March 2013) can login.  Any accounts created before this update cannot. This is preventing most of my users from using the VSA.

    Has anyone seen this before?  I created severity 1 service ticket #6307 for this nearly five hours ago, called and emailed asking for help and still no response.

    All of my high priority tickets have gotten the same type of response recently.  This is becoming quite frustrating.  Can anyone help with this?

  • I don't know if this is applicable to your situation but the AD integration isn't like most (it stinks).  This is what I've had to do after password changes.

    Discovery, domains, domain watch,schedule and status tab, and schedule a full sync.

  • I have noticed this as well and have been recreating them one by one unfortunately.

    I've opened up 4 tickets in the past 8 days and have not received a single response. Makes me wonder what is going on over there.

  • We identified this issue during our recent upgrade from v6.5 to R9.1 and fixed it pretty readily. We only use the AD-integrated authentication for our technicians mind you, so only a few to fix.

    In our case it was easy enough to identify the older VSA user accounts because they were listed in the system as NETBIOSDOMAINNAME\user instead of DNSDOMAINNAME\user.

    Went into discovery > domain watch > policies > users. For each affected user account select the 'Do Not Include User' link and change it to 'Create VSA User' (pick the appropriate options for your VSA users). When done click 'Apply Changes'. It should prompt you to start a harvest process - do that and give it maybe 5 minutes. When that process completes you should find those VSA user accounts change to DNSDOMAINNAME\user format and can log on successfully.

    I was concerned about whether it was creating a new account rather than keeping the existing account (and hence possibly losing scripts and preferences) but there was no issue with this at all - everything was kept exactly as is (presumably it identified there was a matching SID already in the database and just linked the AD user login policy to the existing VSA user account.