Jump to content
[[Template core/front/profile/profileHeader is throwing an error. This theme may be out of date. Run the support tool in the AdminCP to restore the default theme.]]

Community Reputation

0 Neutral

My Information

  • Agent Count
    Less than 100
  1. Creative problems require creative solutions.... Is Ninite Solution is scheduled to run at a specific time every day? Create a script and schedule it to run 30m after the Ninite Solution schedule. Just have two script steps that will delete the shortcut from the two folders you need.
  2. The script we put together has two steps, and makes a couple assumptions. We have @DOMAINNAME@ set as a location EDF Script Step 1 - ExtraData Get Value --- Set variable @DOMAINNAME@ Script Step 2 - WRITE TEXT FILE --- JoinDomain.ps1 $user = "@DOMAINNAME@\%ComputerUsername%" $pass = ConvertTo-SecureString "%ComputerPassword%" -AsPlainText -Force $DomainCred = New-Object System.Management.Automation.PSCredential $user, $pass Rename-Computer "@NewName@" Add-Computer -DomainName @DOMAINNAME@ -NewName "@NewName@" -credential $DomainCred The %computername% and %computerpassword% are then pulled from the location's automate credentials. The Rename-Computer command and likewise the -NewName parameter is optional, our domain join script is really part of our Deployment Process, so we have a parameter in the script the technician enters the NewName while running it. Script Step 3 - Shell Command C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -NoLogo -NonInteractive -command "PATHGOESHERE\JoinDomain.ps1" SCript Step 4 - File Delete ---- JoinDomain.ps1 (because you don't really want that hanging around)
  3. We use this powershell script https://gallery.technet.microsoft.com/Removing-Built-in-apps-65dc387b Use File Write Text to create the files and then execute the .ps1 file as a "Shell Command" "powershell.exe -ExecutionPolicy ByPass -File C:\jmco\RemoveApps\RemoveApps.ps1"
  4. I started writing something yesterday and got busy, but generally it's along the lines of what Gav posted. His wording was so much better than mine I just left it alone. While we have our share of problems, nothing for us is "completely broken". We also use PowerShell, and on occasion vbs, pretty heavily in our scripting, there's a lot of particulars about the scripting platform, but once you get through them, it's pretty great and consistent results can be had. Our current biggest complaint is lack of documentation, there's a lot of "tricks" and things we've learned over the last 3-4 years by either working with the product or visiting the conferences that simply don't exist in documentation, or at least aren't easily discoverable in their documentation.
  5. Thanks for the scripts! I've been wondering, has anyone created any monitors to check for the existence of the relevant registry entries, or would there be a better approach? For instance, the QualityCompat key that needs to be in place for the January updates to install, I'm thinking it would be nice to be alerted if machines are missing it, or if future new machines that come online are missing that key. According to the last MS bulletin I saw, that key is going to be required for the January, and all future Security updates to install. Side note --- does anyone know if the check for that registry key is a function of the installation file, or a function of windows update itself. I'm wondering if by using Labtech, it might ignore checking for that key.
  6. If the different servers are part of different clients/locations, you could use LT admin account defined for that location, I believe the variable for that account is %ComputerUsername% and %ComputerPassword%. As for switching computers, you want to use: Function: Variable Set Set Type: Constant Parameter = 274 Variable Name = computerid Note no %'s or @'s on the Variable Name field PS: For script logging purposes, you need to somehow retain the computerid from the machine you're running the script on, I suggest at the beginning of the script @originalcomputerid@ = %computerid%
  7. Are you sure it's not running at all? If it's running under the LT or system account you won't see it from a desktop session. What is the program supposed to do? Can it even run silently?
  8. We have a "deployment script" ourselves that reboots multiple times. What we've done is after each Reboot command, we have the script sleep for 60 seconds. From recollection, when we set this up, the script would error out when the machine rebooted, but by adding the Sleep command, the machine is back up and the script proceeds.
  9. I'm not as versed in Labtech as some of the other guys herehere, but it sounds like Maintenance Windows may be your solution. You can set custom maintenance windows per client, and set the hours and then configure it to not alert you during those hours.
  10. We've started work on doing something very similar. We utilize two scripts and some EDFs, I don't think any of it is optimal, but it definitely gets the job done. https://www.dropbox.com/s/4i4qaj1df3pxprx/Wirless%20Script.7z?dl=0 Feel free to take a look, let me know if it works for you. If anyone can improve upon it, please share it back with the community.
×
×
  • Create New...