[booster]

REFan,

Have you tried to map first the network path in the script? Like:

net use <driver letter> \<servername><sharename> /user:<username> <password>

Then execute the script installation and remove the mapping afterward, as last step.

Regards

Booster

[booster]

Hi Doug,

thanks for the explanations, I’ll proceed your way up to the next release.

Regards

Booster

[booster]

Hi Doug,

I guess this setting limits the concurrent copies in cached+offline mode enabled (KB copies to targets)? I will try to play with the setting a bit

The odd part is it never occur during the KB copies to targets. Only during the WsusScn2.cab. I tested during a copy of for about 60 KB to 4 targets, the problem never appeared.

Regards

Booster

[booster]

thx doug 😉

[booster]

+1, interested too. Good suggestion martbasi

[booster]

Hi Doug,

Fine enough for me, I just need a way to do it for this dedicated server, even if I have to manage the reboot part myself

BR’s

Booster

[booster]

Hi martbasi,

Thx for sharing it 😉

PS: doug if you can correct the title’s mistake (having”t”). I don’t see how to correct it myself, shame on me

Regards

Booster

[booster]

Hi Doug,

Thank you for the feedback and effort put in the customer requests

Regards

Booster

[booster]

Hi Doug

I agree all is displayed in “all messages” but when, as me, you’re applying 3 cycles of update+reboot on 50 servers or more at a time, having the job steps displayed will ease the troubleshooting if necessary. My request was to display dynamically the number of steps in the job and the actual one. this way is something is stucked it’s really easy to focus on.

Example for a job: 1

1/ dL,install, reboot always

2/ wait offline/online

3/ wait 10

4/ dl,install, reboot if required

5/ wait offline/online

6/ wait 5

===> 6 steps, a column dynamically showing 1/6 then 2/6 etc. can confirm all job steps are done for all servers in the grid, and sort on it if stucked helps to troubleshoot servers with erros. I hope it makes my request more easier to understand

Not exactly. I tested this behaviour on a VM multiple time with always the same issue If we take the cycle:

1/ dL,install, reboot always

2/ wait offline/online

3/ dl,install, reboot if required

4/ wait offline/online

The problem appears after the step 2: I monitored the VM console, steps 1 and 2 were successful but after the 1st reboot the VM shows an update screen with a % displayed, applying a post reboot patch part. When 100% is achieved the VM reboot again, but the step 3 already started, creating the error. Adding a wait after point 2 solved the problem. Maybe add a check for pending install/reboot as part of the ‘Wait for host to go offline and come back online’ is the way to go.

I was able to reproduce the problem each time I tried with the same test VM’s. If you need logs/screen or else, I maybe be able to provide it if I still have test VM’s in a prior patches state. (to check).

Regards

Olivier

[Author]

Posts