Jump to content
DeployCentral
Ted Pruitt

Driver Updates showing as deploying but don't actually deploy - no errors.

Recommended Posts

Title pretty much says it - I have a workstation that has driver updates available. I push it out from the console - console acts like it is deploying. Nothing happens on the workstation end.

I've rebooted both the workstation and the SmartDeploy machine.

I never get an error and if I leave it, the "deploying" status just continues.

 

Capture-sd.JPG

Share this post


Link to post
Share on other sites

This is in the workstation csv log:

9/17/2019 11:29        WSSPI-23270    192.168.160.48    18:60:24:9D:23:8B    1    DriverUpdateMessageProcessor 2.0.3050    This request operation sent to net.tcp://192.168.160.48:8733/Design_Time_Addresses/SmartDeploy.ClientServiceWCF/Message/ did not receive a reply within the configured timeout (00:01:30).  The time allotted to this operation may have been a portion of a longer timeout.  This may be because the service is still processing the operation or because the service was unable to send a reply message.  Please consider increasing the operation timeout (by casting the channel/proxy to IContextChannel and setting the OperationTimeout property) and ensure that the service is able to connect to the client.   

Share this post


Link to post
Share on other sites

Hi Ted,

Sounds like it may be a connectivity problem, but if we can take a look at the Application event log from the endpoint, we can see if if received the command and tried to follow it. Also possible there simply weren't any newer drivers available, as everything installs silently, and the device only reboots if a particular driver requires it.

I'll send you an email shortly.

Glenn
SmartDeploy Support

Share this post


Link to post
Share on other sites

There is no connectivity issue in regards to the network. Can ping both directions. If there are no new drivers - that's fine, but would make some sense to reflect that either in the status or in the log.

I'll look for your email. Let me know what logs you need.

Share this post


Link to post
Share on other sites

Sent. Being able to ping both ways is encouraging, but there are specific port requirements that may not be met here (8733 is one of them, which is referenced in the error message above).

We should be able to see what's going on in the event logs in any case; we'll be in touch.

Glenn
SmartDeploy Support

Share this post


Link to post
Share on other sites

First, I would check C:\Platform on the target system to make sure the Platform Pack was copied there. Then check the System log in Event Viewer so see if drivers are being injected. 

Share this post


Link to post
Share on other sites

@brendanshreve - essentially the issue was something disrupting the installation of the pack. SmartDeploy doesn't seem to handle the failure of an installation very well. What I found was this - let's say I pushed out an installation of Acrobat. If some portion of Acrobat was running in memory, the package itself would be copied to the end-user machine, when it would attempt to run on the user's computer, it would see a component running on the end-user computer, then it would just stop (likely the MSI erroring out) would stop the deployment. No error message on SmartDeploy, just stopped. SmartDeploy client then appears to report back that the deployment is "successful" - however, it leaves the package from the previous install in c:\windows\temp - because the previous install doesn't appear to have cleaned it up. Then, if you try to redeploy - the package sees the package there and - for whatever reason - doesn't use it and doesn't try to overwrite it with a new copy of the package.

So on this particular computer, the solution was to go into C:\WINDOW\TEMP and delete the deployment package. Then go into c:\windows\syswow64\smartdeploy\sources and delete the files in there. Reboot the computer (to make sure there is no component running) and in the computer's "pristine" state of just being rebooted - THEN deploy the package.

As a habit now, if I have a package to deploy, I ask users to restart their computers and then I deploy it and call them when it's done to tell them they can log in. If I have a mass-deployment, I ask all users to reboot and leave their computers in that state or I do a mass-reboot of PCs from PSShutdown and then deploy.

If Jeff or any of the guys at SmartDeploy have another idea of a better way to deal with this - let me know!

Hope this helps, Brendan.

Share this post


Link to post
Share on other sites

That is correct; we are working on how to better address a previously failed Application Pack deployment. The presence of the !sdspk folder in C:\Windows\Temp\ is a good indication that an installation is stuck, along with any files in the C:\Windows\syswow64\SmartDeploy\sources folder. 

We do check for those when we're troubleshooting any deployments. 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...