Jump to content

imurphy

Members
  • Content Count

    237
  • Joined

  • Last visited

  • Days Won

    3

imurphy last won the day on May 6

imurphy had the most liked content!

Community Reputation

11 Good

My Information

  • Location
    Bizkaia, Northern Spain
  • Agent Count
    < 500 Agents

Converted

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I'd go 11-> 12 and then 12 ->2020 but it should be simple enough. If you have a vm rather than a physical server, you can test the update on a copy, or do a snapshot and then upgrade so you can always roll back.
  2. When you say maintenance, do you mean run scripts? If this is the case just schedule them to run on the agent using 'advanced settings' > unmark 'skip offline agents'. If you mean that you want to know when a box switches on so you can connect to the screen, then you can write a one line script which sends a mail to your account with the text '%computername% has powered on'. Schedule that script to run using the above unmarked 'skip offline agents'. You could get even more clever and write a generic script to be used by anyone and which sent a mail to the person who scheduled the script. Look at some of Darren Whites scripts. In fact his Send email script does just this. Also, is wake on lan not available?
  3. Disk space alerting generates emails by default, so no need to go configuring. Same for quite a few other urgent issues. You can modify/create similar funcionality by creating a monitor and applying it to a group and then marking it to alert byt generating emails. From Control Center desktop, open Browse > groups > Services Plans > Windows Servers > Double click on "Managed 8x5" Open Computers tab > Remote Monitors tab The list of monitors it shows only applies to servers with an 8x5 maintenance plan. Click on one like 'Perf - Available MBytes' then click on the Details button at the top. This will display the details of what is being monitored. Beside that on the right there is a dropdown for the 'alert template'. This is how an email would be generated. You can use the canned alert templates or generate your own.
  4. imurphy

    Script Issue

    The way mike said to do it is the way to go. Running a monolithic script again and again on boxes which may or may not have the software already installed and which may or may not already be updated makes no sense. Write one script which installs what you need and only run the script on machines which need it...
  5. Better still, do it the Automate way. Rather than detecting the manufacturer in the script, only run the script on Dell machines. As an example, to push Dell support assist: Create a search called something like Just-Dell-Workstations. Create a group called something like Just-Dell-Workstations. Populated the group with Just-Dell-Workstations search and limit it to that search Create another search which is Machines-Missing-SupportAssist which selects only machines which do *not* have Support Assist installed Create a script called Install-Dell-Support-assist In the Just-Dell-Workstations group configuration > computers > scheduled scripts add a line to execute the Install-Dell-Support-Assist, but limit it to Machines-Missing-SupportAssist The above will run the Install-Dell-Support-Assist script on only Dell workstations which do not have Support Assist already installed No need to add checks in your script.
  6. Well, none of those things is going to work because its simply buggy. Its been buggy for years. It suffers memory leaks and probably other issues. The memory leak is very obvious. A couple of years back I supplied all the info to show that the console crashing issue was definitely a memory leak bug. All you had to do was to use the console for a couple of days and it was guaranteed to crash. The tests in which I managed to reproduceably crash it consisted in nothing more than opening and closing Computer View windows. Around 20 was enough. They tried to blame everything. Configuration, plugins, AV, whatever. I excluded all of these and I was able to finally get them to accept it was a bug. The next release they rushed out a fix for the problem. You now have me to thank for the fact that the desktop client automatically shuts down after a period of time. That was it. No other fixes applied. Nothing touched since then. It still crashes after nothing more than opening windows and closing them.Computer view especially so. Ian
  7. Try the following. Shell as admin: copy <source file> <dest file> >> c:\temp\cpy.log 2>>c:\temp\cpyerr.log it should write two logs to c:\temp (make sure c:\temp exists on the box you are testing on). The cpyerr.log should contain the text of the error which is occurring. Its almost certainly access denied. Ian
  8. Darren White wrote a monitor to do just this. Works like a dream. I've just been searching on mspgeek and I can't find it. It may be better to just ask Darren on the slack channel.
  9. Why not just disable patching? You could just manually run a script on they whole client once a month on a pre arranged day and have the script launch patching. Ok you are adding a manual process here but given the preciseness of the days they do not want to patch it may be easier. Alternately just set them to patch and not reboot. Occasionally it causes problems but if you make sure everything gets rebooted regularly it should be just transparent that they have patched..... apart from the win10 feature updates.
  10. Its likely because chrome has been installed under the users profile. When you execute the above command it executes under system and so doesn't find any installed application called chrome. Try adding a few lines to execute the same command on the users console when they are logged on.
  11. Any reason why you can't execute a console command which consists of powershell.exe -command "myscript.ps1"
  12. imurphy

    Identify version

    You will find that doing this differently will make your life much easier. Your existing script installs a version of software - good. Rather than building a ton a logic into your script, try the following: [optional] Create a search which returns all machines with VPNClient installed - call it VPNClient-installed or something like this Create a search which returns all machines with vpnclient installed and version<>1.3 - call it VPNClient out of date [optional] Create a search for all machines which do *not* have VPNClient installed and call it - VPNclient not installed Create a search for the machines which *should* have the vpn client installed - lets says a search where clientname ='abc' or clientname='def' Create a group, set the group autojoin to the above search for machines which *should* have the vpn client installed Open the group and on computers>scheduled scripts add a scheduled script Select your original script to install the vpn client but on the 'apply to' drop down, select the search we created above 'VPNClient out of date' Add another scheduled script, select the same script you wrote above, on the 'apply to' drop down select the 'VPNClient not installed what you are doing is selecting a group of machines which *should* have the client installed, then running the install script on, and this is important, just the subset of machines in this group which have the vpnclient out of date. Rather than creating one monster script with a ton of checks for different cases, its easier to create one simple installer and let Automate do the selection work and only run the scripts on the boxes that need it.
  13. Simpy put, Mysql is an abysmally unstable product. It requires you to manually configure a load of memory management settings which, if any are too low, it simply crashes. The error messages are rarely in any way linkable to the resource shortage and there is rarely/never any warning that a given resource is running low. There are a thousand tuning guides out there - many say you should never have value X below/above a multiple of value Y - but they often conflict with each other. We had a similar problem a couple of years back. Mysql would just crash again and again. Support got involved after I gave up. They evenually wiped everything, mysql, labtech, the lot and reinstalled everything from scratch and then reestimated the my.ini settings. It still crashed again but after another tweek its been stable ever since. The best way is to get on the slack channel, find someone with a similarly sized installation and get a copy of their my.ini Ian
  14. What you're asking for is kind of a ton of work - export out the per-group monitor configuration for all groups. There are dozens. What you need to do is just pick any alerts you are not interested in and disable/remove them. The biggest ones always used to be the hardware sensors. Theres a script you can run against all nodes which will simply delete those monitors. Search for 'sensor' in scripts. If you then find that something is generating tickets you aren't interested in (perfmon response time alerts for example) then hunt down that monitor and just disable on the branch which you are not interested in monitoring.
  15. Windows doesn't record this information under a standard configuration and since Automate largely only reports on what Windows records there isn't anything to report on. I'd imagine it would be pretty easy to write an event handler to catch application launch events and record them into a file which you then uploaded to Automate and imported into a custom table. The upload and import would be a few minutes work.
×
×
  • Create New...