Desktop Authority Essentials
I'm curious how the upgrade experience has gone for anyone who's upgraded to 9.3. How much additional time did it take for users to log in after the upgrade. Did they experience any errors or performance desegregation for the first login after the upgrade? For companies where regular users do not have install rights, does the defined admin user that is used for "run as administrator" on application launcher events take care of updating the client and Expert Assist? Did anyone do a vulnerability scan on any upgraded machines to verify the POODLE SSL3 issue is now resolved?
We are on 126.96.36.1994 and our upgrades historically have been a big deal in the past (many errors and calls the day after an upgrade as people log in with error messages, blank screens, desktops not loading, wkix32 stuck in a loop, etc...) so we only upgrade when we absolutely must. With our Windows 10 deployments out there we really need DA to start setting up the default printers correctly again, so this is an upgrade we want, but we hope that the install / upgrade issues of the past have been worked out with this version.
We never had a problem upgrading the server. It was always really straight forward... its the clients I'm worried about here. Last upgrade from 9 to 9.1 there were a few dozen machines that would require a few hard reboots until the client updated properly. That causes support calls. I really hope those issues are resolved.
Hello, this is Diana from Support. Since you have experienced upgrade problems in the past, why don’t you call into support and allow us to advise you, and help you prepare for your upgrade to 9.3? You can submit a Service Request at https://support.software.dell.com/ or by calling Support at 800-306-9329.
We look forward to hearing from you.
Quest-Diana VSocial Media Support#WeAreQuest
Our testing has shown basically ok, but I fully expect to see client issues like you're talking about.
- there is still not proper removal of logoff scripts from C:\Windows\system32\grouppolicy from DA8 - The scripts are left in place.
- During uninstall of DA9 to retest the installation process, we found that the DA9 logoff script in the same location is still left in place, which reinstalls the DA9 product on logout after you've uninstalled.
- The reporting tool download to your desktop client contains links to where the server install of reporting is located. So if you installed to D:\Apps on the server, the client installation procedure tries to access files at D:\Apps - this results in a fatal error on the install.
- Something in the logoff process was hanging for long periods (8-10 minutes) - in global options, User Management, Desktop Agent, we were able to change the setting for "Wait before executing the next synchronous application" from 900 down to 10 seconds, and same for last application. Given our shutdown is empty, I'm not sure what it's hanging on.
Thanks, though we are still on 9.1, we sometimes experienced long shutdowns and I double checked our Global Options > User Management Options and we had 60 seconds for the wait before executing the next synchronous application and 90 seconds for wait after executing the last application before ending the windows session. I changed both to 10 in anticipation for this.
Yeah that logoff script plagued us in the past, I think we temporarily created an element to delete them as a one time run option from C:\windows\system32\grouppolicy.
I wish they let you phase the upgrade in, ie) use the great logic to target 9.3 to a computer OU at a time, so we can ease it in instead of require an all at once "quick like a Band-Aid" approach.
I remember our first upgrade issue back in the 8 days was how we handled folder redirection. We would map a U: drive to a users folder in a share and then folder redirection would be mapped to that U: drive. The issue was the DA 8 upgrade would fail because it ran under a different user context with admin rights I guess, and mapped drives are not there when running as (I can recreate this by going into my mapped Z:\apps drive, right click an installer and say run as administrator - it will say the path is not valid). However we learned from this and now do folder redirection based on UNC Path ie ) domain\dfs\users\%username%\desktop for example. UNC path is still valid under that other domain admin context as seen if I go to that same apps drive but with \\domain\dfs\apps , right click a program installer and run as admin- it works.
The next upgrade we did from 8.4 to 9 had issues where when logging on it was just hanging (black desktop screen). Had to press ctrl+alt+del and do end task on wkix32.exe process, then the computer would proceed to log in (though without our DA configurations being applied), The second login would usually be "correct" and upgrade the client.
Then from 9 to 9.1 we experienced the same thing as above like we did when going from 8.4 to 9. It was random but I would have to say it could have been 30-40% of our computer inventory. The problem with support is they would want to see it happen, but buy the time we got them webex in, the problem was gone because it just required another reboot or two of a machine and the people can't sit around all day on black screens waiting for support.
So I fear the same, if not worse going from 9.1 to 9.3. I know we can put out an APB to staff that an upgrade is going to happen and if you log in and sit at a black screen for longer than 3 minutes, hold down the power button to force off the machine and then turn it back on again. But still its going to cause support calls and what if a fraction of those forcing the power off machines have negative effects from an unsupported shutdown. I know we get calls already if they restart improperly and at boot Windows is asking if you want to "start normally".
My next maintenance window is Saturday April 2nd, and I'm not sure if I will be doing this then, or an Exchange CU, or a SAN firmware update, or what. I have plenty of things to keep me busy, but boy I would like to get this upgraded at some point as its real annoying that your default printer does not stick in Windows 10 using DA to set the printers.
We just upgraded to 9.3 from 9.2. We faced the following issues:
1. The servers didn't update their services, so I had to manually update each of them through the Service Management tab. Also, it seemed that the update locked the files on the NETLOGON shares, so we had to reboot our DCs.
2. We ran into the KB 190091 issue. The hotfix was easy to implement and fixed the issue.
Once we got those two issues resolved, it has been running pretty smoothly.
Hey, I would have replied sooner but I have a real hard time with this site (slow loading, sometimes no post controls appear, sometimes there's no link to log in, etc..)
We also had the MapiServer issue at least one vocal person reported it but opening a ticket to get the hotfix resolved that issue. ScriptLogic.MapiServer.exe has stopped working. (190091)
Never had any issues with netlogon, however it did take awhile to right click on 3 DC's and upgrade the services. By awhile I mean it took some time for the yellow icons to turn green.
Also after we got past the installation hurdle from the 9.1 corrupt MSI registry GUID thanks to psexec and the reg delete command and a text file with all computers (after they were all powered on), we didn't have any upgrade issues after correcting that registry key. We've had a rash of signature pads, pin pads, card pinners (were a financial institution), drivers licence scanners, etc... stop working randomly on random pc's... and the only thing I can think of is either a Windows Update regarding USB vulnerability in mass storage devices, or the USB Port/Security upgrade. We've been just deleting the devices out of devmgmt, including the driver, plugging them into different USB ports, re-scanning and re-installing the drivers. In those instances we've got the devices back to working. Some more stubborn cases involved a trip to the registry to delete USB "Filters" as described in some helpful articles after a quick google search.
I've done the server side upgrade from 9.1 to 9.3 three times (two test runs on the server restored to a test network via veeam). In ALL three occasions after the upgrade the web GUI would not work. It was some blurb about the management service not running, though it was. The fix in ALL THREE instances was go go into the start menu and find the Desktop Authority Setup Tool. Then go to the IIS Management tab. In the left hand side pick select an existing certificate and choose the certificate that is the one assigned to the https binding on IIS. A restart of IIS then cured it. Again this was the case in three separate times, so I imagine it was required, but not noted in the documentation.