Edgehill

Not sure if it's the same for network servers set ups, but for online activation we've had similar issues before due to users not having required access to C:\ProgramData\Avid\Licenses\Sibelius. Might not be the same folder, but does sound like it might be a permissions issue.

I've had a look and "checkAuthorised()" is defined in mrbs_auth.inc. Looking at the mrbs_auth.inc for the current and older versions the function now seems to include different checks on the "level" of the page. My guess would be that this is failing as bulkYearMake.php is not a default part of the install so has no level assigned. It looks like there is a bypass switch built into "mrbs_auth.inc", but I could be mistaken with my limited understanding. As a test you could try switching line 197 temporarily to "function checkAuthorised($page, $just_check=true)". If you can then access bulkYearMake after this you need to edit the mrbs_auth.inc to include a level for bulkYearMake.php. If it still doesn't work then you need to delve into the "checkAuthorised()" function to understand what it is doing and why it might be failing.

The "checkAuthorised()" function is not defined within bulkYearMake.php. I'm limited on my understanding of PHP, but I think this pulls from "defaultincludes.inc" and that then pulls from another file (likely functions.inc?). Is your bulkYearMake.php in the same directory as "defaultincludes.inc"? If not it then this could be the issue, so I would test either moving it to the same directory or amending bulkYearMake.php to account for the different path.

What version of the software are you trying to install? Is it one of the newer classwiz versions or one of the older versions?

Unfortunately I haven't been able to get anywhere with this either. From what I've seen the issue is RM based so I wouldn't expect Capita would be able to provide any guidance on this. Since my last update I tried removing all RM packages from a workstation and this seemed to stop the issue form occurring, but I was unable to pinpoint the issue to a particular package as the issue reoccurred at different times each time I started putting packages back on.

You can see .net framework in regedit, if you navigate to "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full" there is a "Version" key.

Strange, the macro theory doesn’t fit what I’ve seen. I’ve joined a raw windows 10 PC to our domain and checked the same GPOs are applying, in this case the report runs fine opening but the template shows “Macros are disabled”. It’s the same for our 2012 R2 RDSH (non CC4) server, template shows “Macros are disabled” but report runs fine. Furthermore I have successfully replicated the issue on Win 8.1 (with office 2016) and Windows 10 with office 2010. I have also found that sometimes after changing various settings the report will run fine for the first attempt but will fail on a second attempt or after closing and reopening SIMS (and rerunning the report). So it sometimes looks like changes have resolved the issue, but on repeat testing the issue persists.

No, unfortunately I'm still having no luck with this. Out of interest are other people who are getting this running RM networks or vanilla windows?

Out of interest what settings did you change to get around this? We have the same issue for all users. I've tried setting the following via GPO with no luck; Enable all macros, Trust access to VBA project object model and adding "%TEMP%" as a trusted location. Any help would be greatly appreciated.

Are you using a proxy server? We used to have Chrome set to use the system proxy, after resetting a profile users would need to open IE to populate the proxy settings in Chrome. If you are using slightly older versions of Chrome (before 70 I believe) you can check proxy settings by navigating to Chrome://net-internals

Are the policy folders on each of your domain controllers the same size? If you run "nslookup [your_domain]" from cmd does it show any unexpected entries? If you check the .ini file, do the necessary users have read permissions to it?

To update, Google Admin fix has now worked for me. Double checked the settings and it wasn't replicating down through OUs, manually setting it on the OUs in question has got rid of the error message.

I left it 3-4 days between changing the setting and testing. But it is possible the change hadn't picked up as I suspect the "real-time presence" is the cause of the issue.

We’ve also had this issue for a while, I did some testing today thought I’d share results in case anyone finds them useful. Issue only seems to affect newer versions of GDFS, 28.1.35.1747 shows issue whereas 27.1.49.1806 does not. I tried the Google admin fix but it did not work for me.

I use EaseUS at home, but I don't know what the license covers.