What times out exactly? The Provisioning task?
Does Windows continue to upgrade / are you caught in a "Core is waiting for client to poke back / Client doesn't install something and thus can't poke the Core back" as it were? (which sounds somewhat like what you're describing based on the "remaining active all day" note)
There's a bunch of situations of how this sort of thing can happen - having a bit more information on how far the line you get / what actually happens would get your specific problem across better.
Also a few general questions / clarifications:
... assuming you're using Provisioning for this? Or are you using something else?
... What version of LD are you on / using? Not going to be a bit fish here, I think, it'll just help give context & clarify any limitations you may run into.
Well when I start it through landesk it just hangs until it times out on the client system it does not even start up on the client computer. tho it does start if click the setup.exe in the extracted iso folder it downloads to the computer before starting trying to start.
The links given above should help you out to get your Windows 10 upgrade rolling.
What I'm guessing is happening is this (as I have rather little to work off of, I'm having to assume a few things - and the below is meant to help explain what is happening in the scenario I think is most likely to be the case):
- You've configured your task to "just" run setup.exe without parameters?
- setup.exe actually requires some form of command-line switches if you want to run it in an automated fashion. To borrow from the above article, something like "/Auto:Upgrade /Unattend:unattend.xml /DynamicUpdate Disable /Copylogs %SystemDrive%\ProgramData\LANDESK\Logs\" - which you didn't add?
What happens on the client as a result is then this:
- Client gets told to "download & run setup.exe"
- Client does download the specified file(s) and runs it.
- Since setup.exe wasn't launched with given parameters, it pops a GUI ... in the user-context of Local System (meaning - you won't see it, as it's in a different user session).
The result of which is you see a process for setup.exe - but it's "hanging" because it waits for GUI input - which you can't/won't give it, as it's in a user-session that you can't access.
This is why packages (including Windows 10 updates) need to effectively run as silent installs / with answer-files -- otherwise GUI's pop up (usually in a user-session that will never have a chance of a real user connecting) and apparently hang. This is something that folks tend to fall afoul of in software packages a few times - it's not defects, it's not bugs - it's just "working as configured" (and as per the above - packages can be configured into a "broken" / "will never proceed" type state).
I hope the explanation helps you understand what (I think likely) is/was going wrong.
In regards to the Win-10 aspect - the above links should help you out get the ball rolling effectively.
Hope this helps.