nomadzer0se7en wrote:
Hi! i think i already got the problem about the location of the installer issue, i just double check my Default Share path on the security options and i notice that i have a back slash "\" on the end of it i tried to remove it and try again the deployment and after that the script works! Thanks for your help!! i attached a screenshot below that status of the intall logs...
Yep, something so simple like a double backslash can cause so many issues. Glad we got to the bottom of it.
JacobH wrote:
Dang Cyber that's a lot of help there - thanks for doing that.
For me, unless the package is huge, or the LAN pipe is small, I generally avoid the packageshare, and hard-code with an IP address... since I don't run many simultaneous deployments, and in case the target computer has issues with DNS. That's just me though.
If I do run with packageshare, and it doesn't work, I generally hard-code with IP address to troubleshoot.
It's all good, its what we are here for, to help each other.
I prefer to use FQDN's, in our environment we have a ton of users that work remotely on VPN's etc. Because of this we I tweaked our scanning options so its a bit more regular with active AD scanning plus manual scans. Couldn't go with GP using lspush and haven't really tested lsagent yet, but we prefer to run agentless where we can.
The other thing I did on the Lansweeper server is create a ipconfig /flushdns task that runs regularly as some of these machines may only be on for an hour a day etc and IP / DNS issues can cause problems.
If I am deploying large packages (eg Bluebeam is 1gb), the package copies it locally first, checks it has copied correctly, displays a message to the user of the install, uninstalls the old version, installs the new version and displays a completed message.
If I didn't copy it locally, what would happen is the uninstall would complete, then it would try and install Bluebeam from the server taking upto an hour or two depending on the connection eg package size. As Bluebeam is a primary application used by our staff in the construction industry, they couldn't be down for 2x hours. This was the best course of action I could find for the deployment. We run quite a few simultaneous deployments, eg recently there was the issue with Google Chrome (exploit in the wild), created a report if below v72, deploy updated Google Chrome, displayed a message explaining it needed to be done, asking them to close the browser, if they didn't the package would do it for them in 5 minutes. That worked really well. We use Windows 10 Pro (no default SOE image as we mostly have a base setup), we have a static group that we add machines to for SOE deployment, this pushes out all our standard apps, explorer configurations, decrapifier script to strip a bunch of Windows 10 bloatware but also sets a predefined start menu layout.
LS can be very powerful.