Ted Pruitt Posted September 17, 2019 Report Share Posted September 17, 2019 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. Link to comment Share on other sites More sharing options...
Ted Pruitt Posted September 17, 2019 Author Report Share Posted September 17, 2019 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 More sharing options...
SmartDeploySupport Posted September 17, 2019 Report Share Posted September 17, 2019 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 More sharing options...
Ted Pruitt Posted September 17, 2019 Author Report Share Posted September 17, 2019 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. Link to comment Share on other sites More sharing options...
Ted Pruitt Posted September 17, 2019 Author Report Share Posted September 17, 2019 And the console still shows as updating drivers - nearly 2 hours later... Link to comment Share on other sites More sharing options...
SmartDeploySupport Posted September 17, 2019 Report Share Posted September 17, 2019 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 More sharing options...
Ted Pruitt Posted September 17, 2019 Author Report Share Posted September 17, 2019 We leave all ports open inside our network - and both the workstation and endpoint exist on this inside net. So ports aren't an issue. Link to comment Share on other sites More sharing options...
brendanshreve Posted February 20, 2020 Report Share Posted February 20, 2020 did you ever find a resolution to this issue? I am having similar problems with only 1 PC in my environment. If you found a fix for it, could you respond back letting me know? Thanks! Link to comment Share on other sites More sharing options...
Jeff Harris Posted February 20, 2020 Report Share Posted February 20, 2020 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. Link to comment Share on other sites More sharing options...
Ted Pruitt Posted February 27, 2020 Author Report Share Posted February 27, 2020 @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 More sharing options...
Jeff Harris Posted February 27, 2020 Report Share Posted February 27, 2020 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 More sharing options...
Ric76 Posted September 15, 2021 Report Share Posted September 15, 2021 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 More sharing options...
SmartDeploySupport Posted September 16, 2021 Report Share Posted September 16, 2021 Hi Ric76, We'll follow up via email - we'd like to troubleshoot this further. Glenn SmartDeploy Support Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now