Jump to content
DeployCentral

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


Ted Pruitt
 Share

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

Link to comment
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.   

Link to comment
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

Link to comment
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

Link to comment
Share on other sites

  • 5 months later...

@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.

Link to comment
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. 

Link to comment
Share on other sites

  • 1 year later...

I am having issues deploying Device Driver updates to my systems. It only deployed to my Admin Machine but not the rest of the department. Users do get the message and select either continue or defer for up to 60 minutes. If they select continue the message gos away and nothing happens, but it does say Installing Updates from my SD Console, but never finishes. Do you think there could be a policy standing in the way? Would you know by any chance which policy it may be. Thanks. 

Link to comment
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.

 Share

×
×
  • Create New...