I must have done over 100 installs of DNN (dnnsoftware.com) now, and I have never seen the "wizard" complete correctly. It always hangs at 28%. Upgrades usually hang at the 53% level.
This appears to be a user interface fault, because if I wait long enough - how long? - I can navigate to the site and all is working perfectly. If I don't wait long enough, some part of the installation process restarts and gives me a site without a superuser account.
The installation process does not appear to have been adequately tested. Anyone know how to get the "wizard" to complete correctly?
I haven't experienced this high of failure rate with the installation or upgrade.
In order to diagnose the problem, do an upgrade. Before applying the upgrade, set the AutoUpgrade key in the web.config to "false". Then initiate the upgrade by going to:
[baseurl]/install/install.aspx?mode=upgrade.
Instead of the simple progress bar, you will get a detailed report of the extensions and items being installed or upgraded.
Before installing, make sure your file permissions are set appropriately on the website folder and you follow all of the steps as per the installation guidelines.
Also, if it turns out the issue is timeouts during the install due to a slow server, try increasing the execution timeout in the web.config in the <httpRuntime> node. The default executionTimeout is "1200" which is 20 minutes. if your upgrade or installation is taking longer, increase the value.
Related
Has anyone else encountered this problem:
Every month I apply windows updates to servers using SCCM Software Update Groups. Some servers are considered lower priority so I push the updates as required to the server and expect the updates to install and the server to reboot if necessary during its assigned maintenance window only to find out that the some of the updates are failing. With experience, I have found this is because the system is waiting for a reboot. I would expect that SCCM would know that there is a pending reboot and reboot the server during the maintenance window to finish applying the updates but it does not. It seems as though these are "pending reboots" that SCCM cannot detect.
As a result, this requires manual intervention each month on a dozen or more servers that have to be manually rebooted in the middle of the night so as to not interrupt production.
One of the biggest culprits to this issue is the monthly Malicious Software Removal Tool. It always seems to fail to apply then works after a reboot.
The Computer Restart related setting can be configured in the "Client Setting" node on your console. No matter if you determine to use the Default client setting or the custom client settings, you should make sure that that the value for the restart temporary notification interval and the value for the final countdown interval are shorter in duration than the shortest maintenance window that is applied to the computer (the default values are 90 and 15 mins). This is important for the deployments which require a reboot completed on your clients.
Additionally, you can examine the logs on the client-side as below:
Update deployments related logs: UpdatesDeployment.log, WindowsUpdate.log
Reboot & Maintenance related logs:RebootCoordinator.log,ServiceWindowManager.log
More details about how to track the Update deployment process in ConfigMgr can be found here.
I have MQ V8.0.0.2 installed in my system and I am applying the fix pack to upgrade it to 8.0.0.5 using the silent install method. It runs successfully and finishes but dspmqver still says the version as 8.0.0.2.
It is on a Windows 7 machine 64 bit. The exe file I am using to apply the fix pack is WS-MQ-8.0.0-FP0005.exe.
I am not getting any errors in the command prompt. I followed the installation instructions IBM suggested while downloading the fix pack. I stopped the MQ manager and then ran the command WS-MQ-8.0.0-FP0005.exe -f silent_install.resp
I gave the response file name along with its path. But its still not working.
Update
On a multi-installation setup the update was being applied properly but to a different installation. To fix the problem, run amqicsdn.exe as described in Applying maintenance level updates on IBM MQ servers in the Windows maintenance Tasks section of the Knowledge Center.
amqicsdn MQPINSTALLATIONNAME=name MQPSILENT=1
This invocation sets a pointer to the installation that is to be updated.
The response file tells the installer what to do and what to install. Depending on what is set there, what you are seeing is what would be expected.
Specifically, the MQPREBOOT and MQPINUSEOK parms tell the installer whether or not to continue if a file it needs to update is in use. There are two likely outcomes here.
1) The maintenance was applied correctly but because files were in use it will not show up until after a reboot.
2) The MQPINUSEOK parm told the installer to bail out if the files were in use.
On Windows, even though the QMgr is stopped, the service continues running. Depending on the MQPINUSEOK setting that would either cause the install to fail or to complete pending a reboot.
It is worth noting that installing anything on Windows requires a couple of reboots. The very first thing before running the install or upgrade is to reboot. That ensures that the registry is saved at the current values. It also ensures that if someone else's app has gone rogue with a memory leak or other issue, it gets cleared before your MQ install proceeds.
After the install, reboot again to ensure the registry with the new MQ settings is saved. That's because if the server crashes, you want the last known good registry entry to be the one with your install or upgrade reflected in it. That also ensures the services still start as expected.
Finally, I'm unsure what "the installation instructions IBM suggested while downloading the fix pack" are but the official instructions are in the Knowledge Center section Windows: Applying maintenance level upgrades on IBM MQ servers. Among the other information you will find there is that the location for the installation log is either specified in the response file or defaults to amqicsdn.txt in your TEMP directory (%TEMP%).
Try to stop the Message Queue Manager and then run the installation command again (after modifying the silent response file). If you still face this issue, check if you have a "C:\Program Files\IBM\source\WebSphere MQ 8.0.0.5" folder created and then run the "amqicsdn.exe" file. That should resolve your issue!
I have a remote database and a copy of nopcommerce running locally (from Visual Studio). During the first run I hit the install button and the page still appears to be loading some 40 minutes later.
I looked into the database and all the tables seem to be there. I didn't bother to copy sample data, so there shouldn't be that much stuff to be done beyond creating tables?
So the question is how long should the installation last? Maybe it is ok to assume that it's done and I can ignore the part where page still appears to be loading?
Your assumption about "it's done and I can ignore the part where page still appears to be loading" is absolutely correct. Usually installation takes 1-4 minutes (depends on your hosting specifications).
But we also experienced this issue several times when the installation page hangs (but we know for sure that it's already completed).
It can take 5 minutes or more to install NopCommerce on remote database when running Nop on local machine. It's probably better to do the installation on local DB (or put Nop on the same remote server as the database).
In my case Nop would hang after the installation was done, but likely it should not happen with a local DB (the hang is probably caused by the long installation time).
I'm running GitLab on Centos 7. GitLab was installed using YUM.
The initial gitlab version was 1.7.12.2.
The problem is with the WEB interface of the GitLab installation.
I'm trying to get the browser session to timeout so that it forces you to login again after a certain period.
I have noticed that a change request was implemented, so I upgraded from 1.7.12.2 to 1.7.14.3 using yum update.
Under the Administration setting (in Web UI) I can now see the extra parameter where you can set the timeout. I have now changed it tt two minutes(for testing so I don't have to wait so long), but it simply does not work.
I have also tried something bigger - 5 minutes - not working.
I have also done a gitlab-ctl stop, then gitlab-ctl reconfigure and then gitlab-ctl start. The new value still shows, but the browser session still does not timeout.
I have also created a new CentOS 7 installation from scratch, installed GitLab via yum with version 1.7.14.3 - this is as-is from the installation - so no previous upgrade problems or similar problems.
I have tried different browsers (FireFox and Chrome) on Windows 7/8, Even Mac. I have also cleared the browser cookies to make sure it gets the latest after the updates. No change in behavior.
Changing the time still has no effect....
Anybody with an idea what I'm doing wrong?
The truth is I think there is a bug in the current session expiration mechanism. See https://gitlab.com/gitlab-org/gitlab-ce/issues/2129
Short answer, your not crazy ;) Hopefully we can resolve this issue shortly.
Thank you in advance for considering this question. If a similar question existed, I was unable to find it.
The Issue: Our company packages an application into an MSI. This MSI when installed outside of any GPO properly updates, blocks attempts to downgrade (or move from a higher revision to a lower revision), and never has trouble uninstalling previous versions of the application regardless of how long ago those versions were created/installed. For example, we can install version 1.2.3 and then install version 2.3.4 and the application will properly install without issue. However, we work with a customer who uses GPO to deploy our application to hundreds of PC's. Each time we have provided an updated version of the application the following has been indicated:
On any machine where a previous version of our application was installed via GPO, no matter what the previous version is, the update successfully installs without issue.
On a machine where the application was manually installed (outside of the GPO), and an attempt to update the application via GPO is made - either the application is installed in addition to the old version, OR there remain registry keys to the previous version of the application and the application cannot open/run correctly. In this case the registry keys must be manually removed, and the install is then attempted again from a clean machine.
What we know is that on any machine where the application was originally installed via GPO - updating the application is no problem. On every machine where the application was not installed with the GPO in the first place, updating via GPO fails with one of the problems presented above.
My question is: Is there a technical issue with how the installation is being handled partially through the GPO and partially outside? Does the GPO need to be responsible for the entire life-cycle of the application? OR is it a reasonable expectation that the application be updated both on machines where the original version was manually (outside the GPO ) installed, and when it was installed initially from within the GPO?
One solution we are aware of is simply having all computers manage the application life-cycle (since we know updates work in that environment already), however this would mean that many computers would need to have the manually installed versions removed by hand - and then properly handle the installation through GPO which is an extensive bit of work.
We would greatly welcome any solutions, references to technical documentation that formally shed light on the proper management or expectations here, or links to information. Our research suggests that it is "best" to manage the entire applications life-cycle inside the GPO - but I have as of yet been unable to determine that it is 100% necessary to do so.
Looking forward to any assistance. If any further technical details are required to help the viability of the question, please don't hesitate to request such details.
If you end up with two versions installed in Control Panel, then all other things being correct, the most likely explanation is that you upgraded a per user install with a per machine install (or vice versa). In the GPO world that's related to assigning it to a user or to the computer, something like that. That's easy to verify by getting a verbose log and checking the FindRelatedProducts actions for an indication that another product was found but in a different context.
When you're in GPO mode all the time, I assume each one (whether it's per user or per machine) is consistent, therefore upgrades always work, but they don't work cross-context.
I believe GPO suppresses the UI in most cases, and the UI (or the UI sequence) is sometimes where per user/per machine is set. That might be something else that would cause it, depending on how the GPO publishes to the computer or the user.