We run a VR lab at the University with 19 Oculus Rift and 4 HTC Vive stations, open to all faculty, staff, and students. We require each user to sign into Windows with their own University account, and to create their own Oculus account. Beginning in mid February, new Oculus users have hit a brick wall in their Oculus setup, with Oculus error OVR88948175.
Oculus is evidently trying to download something to "C:\Program Files\Oculus\Software", which requires admin privileges -- even though the Oculus software is already fully installed on the machine. If a user clicks the "Change Location" button and navigates into their own folder space, it has no effect:
The pathname in the dialog doesn't change -- which is an obvious bug -- and there's no way past this error. We've been discussing this with Oculus support, but their bottom line is: "we aren't able to provide much support for this situation, since we recommend using an admin account with the software." As my colleague put it to them, succinctly: "if the Oculus software only works for admins, it does not work for us." We are not going to provide admin accounts to everyone on campus.
We have been using Oculus hardware and software since the DK1. We've incorporated Oculus into our in-house VR software. Our lab is a seed for VR on this campus, and departments across campus are looking to us for experience and advice in setting up their own labs. Investment is set to grow exponentially. This was never a problem until a few weeks ago, evidently related to some recent Oculus software update. It affects only new users. Old users already set up with non-admin accounts continue to work.
Unless we can find a way past this roadblock, we can no longer recommend Oculus for a large-scale University investment in VR. There are many alternatives ...
Has anybody else hit this error? Any known work-arounds? Are we the only ones attempting to operate such a facility?
Just wanted to echo the sentiment above, found this thread whilst searching for a related issue. We are also an educational institution, albeit with only three Rift workstations, however we also do not and will not grant local admin access to end users. UAC has been around a long time now and "run it as admin" was an accepted workaround in the early days but doesn't carry any weight now. We have over 300 workstations spread around multiple floors and the havoc wreaked by allowing anyone to install anything and change all settings doesn't bear thinking about.
Regarding the issue reported, my only success was logging into one of the workstations as an admin account, changing the library location to a user writable area and then letting the original account try again. As with the OP simply changing it to the same writable location as the user themselves did not work and generated the generic error that at least led me here.
There's been no response in this thread but I hope this feedback can at least be silently integrated into future development of the Rift software.
As the sole support for our VR (Oculus) Lab at UCSD, I'll also echo this concern. Every other update the Oculus team puts out breaks the software on our lab workstations. Each time I put in a ticket with Oculus for the new issue(s) they reply with "It must be your group policy settings." After I send them the logs. That coupled with the fact that they release no IT relevant patch notes is exceptionally frustrating. The first time they broke the software, they added an NTservice account that needed permissions to run the OVRservice, the second time they broke it, I scripted the OVRService to restart at login and log off so it didn't give us the infinite spinning loading circle in start up whenever one user logged off in another logged on and tried to start the program. And now we have this issue for the 35 Oculus rift headsehe that we have.
When it comes time to upgrade or replace these Oculus headsets, I will be recommending that we move away from your product. I see no point in wasting 20-30 hours troubleshooting your software every single time you guys change something in an update. Also, with the new Oculus coming out we can't risk any percent of our students being unable to use your product because their eyes might not fit your sweet spot for the focusing mechanism.
One of my colleagues finagled a reliable workaround that seems to work from non-admin user accounts. It seems that the Oculus setup gets stuck with a missing registry entry, and yet users can double-click this REG file to create the entry and then successfully run the Oculus setup, all from non-admin accounts:
where the # are hex digits of a GUID that he fished out of his own registry. I don't know the ramifications of duplicating that GUID for each user, but so far this has reliably fixed the problem with no apparent adverse side effects over the past several weeks.
Another colleague arranged for this to happen automatically at user sign-in, so they no longer need to manually execute the REG file.
I did some testing and the only registry value that needs to be added for users to be able to finish the Oculus setup is "HKEY_CURRENT_USER\Software\Oculus VR, LLC\Oculus\Libraries", the rest of the values will fill in and allow you to continue the process, so there is no need to mess with GUID stuff. Simply adding a GPO for that to be added to the registry on login will fix this issue.
Adding the missing registry keys to HKEY_USERS\.DEFAULT\Software should fix this for everyone who logs in. Run the following command in an administrative command window. REG ADD "HKU\.DEFAULT\Software\Oculus VR, LLC\Oculus\Libraries"