Some quick answers:
- No, not that I am aware of
- Yes. If you're not sure, make a backup of the ProgramData\QlikTech folder before upgrading.
- That could be the case, yes. Make a copy of the ProgramData\QlikTech folder and restore it after the Windows upgrade.
- Usually only on each server where there is a QMS service running. I guess in your case that means PRD and DEV.
- If you mean Qlik apps, then not that I am aware of. Just the documentation here: Upgrading QlikView ‒ QlikView
Everything depends of course on the complexity of your original set-up.
My 2cts? First perform an upgrade to QV12 on the DEV machine and check every corner for holes and anomalies. Then proceed to upgrade PRD and Web Server.
[Edit] Seb server? There is no Seb server in QlikView,..
I found a tool that addresses #1. It is very close to exactly what we need and much better than manually entering everything in QMC into Excel.
It is the QVPR Analysis 2.1 from Rob Wunderlich, found here: Tools | Qlikview Cookbook. I can get a list of what's published, reload schedule, and who is authorized to view the apps (among other things). Very handy tool.
Thank you both for the advice. The Upgrading QlikView ‒ QlikView link is very helpful, too. My manager seemed familiar with its content.
His primary concern now is item #1. We would really like to have something that reads and gets something useful from the meta files. I.e., Who and what AD groups can access each .qvw. We would like to audit who has access to what. Looks to be very manual process.
Thanks again for the help!
You might find my upgrade notes useful as well.
Are you running Publisher?
When you say you want to audit who has access, is it that you want to expand the AD groups to usernames and match those up with the qvws?
Hello, Rob. Yes, I've reviewed your upgrade notes (and also installed/used your ScriptRepository, ran the v12 upgrade check (very handy)). Thank you for the knowledge and tools.
Yes, we're running publisher. Initially, we did want to be able to view employees in the AD groups. But I think that as long as we have the group names, we'll be fine. I have access to an AD view where I can join on the AD group and get a list of names. Of course, if the functionality is in your application and I missed it, it would certainly be nice to have.