SMM had to do a few of these too. Security is tightened up a bit in 14.x.
We wrote a simple script to assign new people to the old reports.
This happened to us and I didn't quite twig it was inactive records. We have a 'Schedule' User for some of our reports (Membership Update Utility) so we can see the update was by the schedule rather than a specific user. As that is the only thing that record is used for it often becomes inactive. Does this mean that those reports will stop working when this happens?
Was this documented somewhere?
Kelly, I'm curious, do you have some custom process that automatically inactivates users? We have loads of single purpose accounts like that, but I never worry about them being inactivated.
Nothing custom. That account isn't used very often.
Oh, so someone is coming along and manually inactivating it? I use the "location" field on user accounts to sort them by department, but also use, so I have a "Service" location, and any of my automatic scripts that manage user accounts know to treat "Service" accounts (not to be confused with the new "Service" account type in v14!) differently.
It is indeed the fact that there were several security-tightening things in v14.0 that contributed to this. One was that we discovered that inactive users were still able to make REST calls and this was not a good security practice. I will admit that we didn't anticipate that reports schedules owned by an inactive user would fail and this certainly should have been noted in the upgrade notes.
If reports scheduled by former employees are deactivated will that cause the report server to fail? Do the report schedules need to be deleted?
ThanksJess LevySan Francisco Opera
Hi Jess,
The other reports didn't fail for me. But we did need those reports scheduled by former employees, so I just wound up reassigning them to me in SQL.
Further digging and we do have a custom job running that Inactivates users that haven't logged in in the past 90 days. As Standard Functionality locks the account if the password has expired I'm tempted to disable that custom code. As long as the reports will still run on a locked account. Can anyone confirm that?