I guess this will probably just end up being a complaint, but we are a long time customer of this product and this is just really not acceptable:

[NOTE] All: If you get problems with AD logon type then please logon with normal VC user and delete the AD user and add it again - or use the new AD group features

It appears we can connect to all of our servers, but we can't open any jobs due to the error:

"Permission denied. Current user does not belong to any group."

To have to re-configure every one of these servers manually is going to be very time consuming. The previous implementation worked great. Why change it? The [NOTE] says " delete the AD user and add it again - or use the new AD group features".

We have to add the AD Group back and then the user can log back in and it works correctly. I'm not sure what is meant by "new AD group features" - other than the interface looking different, it appears to work the same to me.

Same problem here. Grrrrr

Why change it?

We got a lot of feature requests that users wanted to do the following:

1. base permissions on AD groups instead of having to set permissions for each individual AD user
2. be able to work against multiple AD:s
3. display more information about the AD user or group

To do this we had to re-collect information. The information we needed, to comply with new format, could not be auto-updated. That is why you needed, in some, but not all cases, delete existing users.

I think this new approach will let you handle AD users better as you do not have to search up individual users but use AD groups as source instead.

---

I think this new approach will let you handle AD users better as you do not have to search up individual users but use AD groups as source instead.

I don't what you mean. We were using an AD group already, not individual users - we don't set permissions on either, all users are administrators (we're a small team). In fact, this does not help us in the slightest and our team had to spend almost 3 hours yesterday updating all of our servers due to this change.

So, previously, you were able to select some groups in the settings. But there was no relation to what permission a group member gets for each group. With the new functionality you decide what permissions each group should have.

---

For example,

in the new version you can say that "Administrators" group get Edit permissions and "Users" group get readonly permissions.

---

We found potential cause to that old groups were not converted correctly. This has been fixed here:

http://www.visualcron.co....aspx?g=posts&t=4656 

---

We got hit by this issue last night when upgrading from 7.2.1 to 7.5.1 (I thought it was solved in 7.5.1). We previously disabled the built-in admin account and use only AD logins, like a real business, so of course we could do nothing and had to roll back the install because nobody could get into the user permissions dialog. Since client and server version has to match always (whether you check or not - we've had things get very screwed up by using mismatched versions) we can't really test this in a test environment without some pain and had to roll back three servers.

Now I'm trying to find a good path forward from 7.2.1 to 7.5.1. So far it seems to be this:

1) enable the built in admin account (yuck)
2) Upgrade
3) AD Users don't work, so log in with Admin, add AD groups, remove users

The problem with this is that all of the created by and modified by fields on all the jobs show "user name not found" which is absolutely unacceptable. Here are some other notes about the situation before and after the upgrade:

- Before the upgrade, AD users are currently only in "temp group for [username]" and not in administrators, yet have administrative access due to what I can only assume is coincidence.
- Even after adding the AD groups that contain the users, AD users still don't work in 7.5.1, despite being added to the Administrators group (user not in group message)
- AD users only work when you delete them and add their group. But we cannot have hundreds of jobs without a created or modified by name.

Any thoughts?

We got hit by this issue last night when upgrading from 7.2.1 to 7.5.1 (I thought it was solved in 7.5.1). We previously disabled the built-in admin account and use only AD logins, like a real business, so of course we could do nothing and had to roll back the install because nobody could get into the user permissions dialog. Since client and server version has to match always (whether you check or not - we've had things get very screwed up by using mismatched versions) we can't really test this in a test environment without some pain and had to roll back three servers.

Now I'm trying to find a good path forward from 7.2.1 to 7.5.1. So far it seems to be this:

1) enable the built in admin account (yuck)
2) Upgrade
3) AD Users don't work, so log in with Admin, add AD groups, remove users

The problem with this is that all of the created by and modified by fields on all the jobs show "user name not found" which is absolutely unacceptable. Here are some other notes about the situation before and after the upgrade:

- Before the upgrade, AD users are currently only in "temp group for [username]" and not in administrators, yet have administrative access due to what I can only assume is coincidence.
- Even after adding the AD groups that contain the users, AD users still don't work in 7.5.1, despite being added to the Administrators group (user not in group message)
- AD users only work when you delete them and add their group. But we cannot have hundreds of jobs without a created or modified by name.

Any thoughts?

Yes, so preferably, if it is important to keep users I would enable the admin account. Then you just reselect the user in the Permissions dialog so that all (missing) information is filled in. In 4/5 cases this happens automatically, but we could examine your file to see why this does not happen. In order to do that you need to zip the settings folder from the installation folder and send to support@visualcron.com. Maybe we can come up with a fix for missing data in your case.

---