Live Meeting 2007 add in reboot pending to complete installation
Hi I posted this topic in the wrong forum several days ago and haven't recieved any feedback, so I've finally decided to post in the correct forum. I have been tasked to deploy the Live Meeting Console and Add In 2007 to the entire workstation environment for our agency. I've had no issues until this point (did a development deployment to 10 systems, everything went swell). Finally I did a small pilot deployment durning production hours (to 5 systems). After checking the advertisement status of all systems (SMS is the deployment tool), all were pending reboot. I thought this may have been due to Outlook being in use at the time (the msi logging shows a whole slew of .dll files that cannot be replaced while Outlook is opened). But upon further investigation, the following message from the logfile is what has prompted a reboot:
Info 1903. Scheduling reboot operation: Deleting file C:\Config.Msi\8742cab.rbf. Must reboot to complete operation.
Info 1903. Scheduling reboot operation: Deleting file C:\Config.Msi\8742cac.rbf. Must reboot to complete operation.
Info 1903. Scheduling reboot operation: Deleting file C:\Config.Msi\8742cbf.rbf. Must reboot to complete operation.
This step occurs right after the InstallFinalize step, not really sure why this would hold up the successfull installation of the product. If anyone out there has encountered this issue during deployment of this product, please inform me of a way around a reboot. Normally our deployments are intended to be as least intrusive as possible, but I guess if there's no way around it then I'll just have to deal with it. Thank you.
Info 1903. Scheduling reboot operation: Deleting file C:\Config.Msi\8742cab.rbf. Must reboot to complete operation.
Info 1903. Scheduling reboot operation: Deleting file C:\Config.Msi\8742cac.rbf. Must reboot to complete operation.
Info 1903. Scheduling reboot operation: Deleting file C:\Config.Msi\8742cbf.rbf. Must reboot to complete operation.
This step occurs right after the InstallFinalize step, not really sure why this would hold up the successfull installation of the product. If anyone out there has encountered this issue during deployment of this product, please inform me of a way around a reboot. Normally our deployments are intended to be as least intrusive as possible, but I guess if there's no way around it then I'll just have to deal with it. Thank you.
0 Comments
[ + ] Show comments
Answers (6)
Please log in to answer
Posted by:
anonymous_9363
16 years ago
It's likely that those rollback files are still connected with the replacement of the Outlook DLLs. Have you tried a deployment to a machine with Outlook not running? If that proves to be the case, I'd toy with the idea of adding a Custom Action to detect Outlook.EXE as a running process and act accordingly, either proceeding or abandoning. If the install is abandoned, you may want to construct a method to tell the user what happened. Not knowing SMS that well, I don't know that scenario is handled.
Posted by:
danr29
16 years ago
Yeah I'm beginning to think that I'm going to have to use a CA that kills the Outlook.exe thread if it's running. I guess I'll have to create a custom notification msg proir to the installation explaining that Outlook will be closed b/f the Live Meeting add in upgrade. Man this is just going to create more work for me.
Posted by:
anonymous_9363
16 years ago
Why not first send a round-robin email explaining that a deployment will take place on day 'x' at time 'y' and that users need to be logged out of Outlook in order for it to take place and, if they're not, Outlook will be forced closed, with all that that implies. People can't complain if something happens, about which they were pre-warned. But, needless to say, they will.
Posted by:
Deployee
16 years ago
We are deploying Live meeting 2005 to all workstations with SMS without reboot with the LMConsole_en_us.msi and /qb! switch. We do deploy to workstation, not to user, not sure if that makes a difference. I did not package this particular app, I would have to check with my partner in crime, she has the early shift and is gone for the day. Let me know if you still need info and I'll follow up with her.
Posted by:
danr29
16 years ago
Deployee;
I did the deployment for the Live Meeting 2005 Console and Add-in a year ago and like you said, didn't experience these issues. I beleve the issue now occurs due to the upgrade of the Add in from 2005 to 2007 (and additionally at the time Outlook being open). My only option is to kill the outlook.exe thread b/f the installation takes place.
Vbscab;
Like you suggested, we normally do an agency-wide email (plus intranet notifications) when it will affect the entire agency. You would assume this is ample notification (and would make the user responsible if they didn't know about it), but still somehow those few users that didn't get the message make us look like we didn't do our job correctly. I guess being in a career-field not IT related must be pretty sweet, because you can just disregard extremely important bullitins such as this and not be held responsible. For us, you can do everything in the world to make sure the deployment goes as planned but when that one person doesn't read the email it looks like the entire deployment failed. Go figure.
I did the deployment for the Live Meeting 2005 Console and Add-in a year ago and like you said, didn't experience these issues. I beleve the issue now occurs due to the upgrade of the Add in from 2005 to 2007 (and additionally at the time Outlook being open). My only option is to kill the outlook.exe thread b/f the installation takes place.
Vbscab;
Like you suggested, we normally do an agency-wide email (plus intranet notifications) when it will affect the entire agency. You would assume this is ample notification (and would make the user responsible if they didn't know about it), but still somehow those few users that didn't get the message make us look like we didn't do our job correctly. I guess being in a career-field not IT related must be pretty sweet, because you can just disregard extremely important bullitins such as this and not be held responsible. For us, you can do everything in the world to make sure the deployment goes as planned but when that one person doesn't read the email it looks like the entire deployment failed. Go figure.
Posted by:
anonymous_9363
16 years ago
Hi, Dan.
I completely agree. That's a culture problem which I've experienced at other clients. They're the same idiots who ask for Windows Update to be turned off because it disturbs their work and/or insist on keeping their life's work on their workstation's hard drive. I never let it bother me, though: I know I did my job and if they can't read and choose to lay the blame for that elsewhere, that ain't my problem! I used to have a copy of an email thread from one of this idiots, which he'd CC'd to just about everybody in senior management at my then client. The last message in the thread stated that all emails from IT were sent by an Outlook rule to an 'IT' folder and that, "every now and then, I have to delete all your junk." No comment from me, or anyone else, was required.
I completely agree. That's a culture problem which I've experienced at other clients. They're the same idiots who ask for Windows Update to be turned off because it disturbs their work and/or insist on keeping their life's work on their workstation's hard drive. I never let it bother me, though: I know I did my job and if they can't read and choose to lay the blame for that elsewhere, that ain't my problem! I used to have a copy of an email thread from one of this idiots, which he'd CC'd to just about everybody in senior management at my then client. The last message in the thread stated that all emails from IT were sent by an Outlook rule to an 'IT' folder and that, "every now and then, I have to delete all your junk." No comment from me, or anyone else, was required.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.