my plan is to get an easy overview of customer servers with the installed roles to know in seconds which server is for example the Exchange server.
Actually we add comments with the roles of the server. But that's not comfortable. You have to click on every servers comment field to find the right one.
Another idea was to modify the views with the required serverroles. But what should we use if we want to filter a DC???
Another idea was to modify the cutomized field in the Audit section --> Systemoverview . It's easier to switch between the servers. But not perfect.
Any recommendations are welcome.
We created a custom field named "TypeOfAgent", then we scheduled a procedure on our default template account (from which every new agent is copying settings at installation). This procedure populates the above mentioned custom field with the help of several IF statements, looking through files/registry or whatever to determine which type of agent it is..
@Micke : Are you willing to share the procedure?
Another way would be to create views based on what applications are installed.
For an Exchange server, you can get detailed views depending on what role in the Exchange enviroment you want. Ie: you want the Edge Transport server? You want the mailbox database server?
For Exchange, create views based on the information you need. A quick example would be to only show agents have "store.exe" installed, or "EdgeTransport.exe", etc.
Domain controllers?Don't look for an installed application. Instaead use an advanced view filter to only show domain/workgroup of "*(dc)*"
View filters are very powerful, use them to your advantage!
ok. I agree with you that it's the best way to work with different views.
But what should I do to see only AD Servers, DNS servers and DHCP servers. It seems that if I use the application as reference it must be an exe ? But what should I use if I only find a msc ( in my opininion dns.exe is not the appropriate file ) .
What did you do to find out in seconds which one is - for example - the DNS server at the customers site????
dns.exe should only exist if the machine is running a dns server.
AD servers would be the "(dc)" tip I posted earlier.
DHCP servers actually run as a svchost.exe, so that will be a pain to do with a filter, but you can use the same way outlined below to quicky find the DHCP server on the network, just look for the DHCP server column.
You can easily find the DNS server at the customer's site without any view filters. Look at the overall agent status screen. There's a Primary and Secondary DNS column (you might have to add the column) for each machine. The primary DNS for the majority of the machines should be pointed to the DNS server on the network. Then you just look at the IP address of the machine and find the one that matches.
I use a Procedure that I've altered a little called Audit Roles, it searches for particular services etc. then updates a custom field with the results. Not sure where I got this or if it comes as part of the supplied procedures. If it's not in the list let me know and I'll post something up here tomorrow.
add "NOC_Role" as a custom field in Kaseya, it shows you all of the important things that are installed on a server.
I don't know exactly how he put it there but a Kaseya rep put in there when we were on a introductory call with them (they were showing me and a few of my co-workers kind of the basics of Kaseya) It tells me whether Exchange, dns ect. are installed on that server.
This is the Kaseya procedure that populates the NOC_Role custom field.
The Kaseya NOC were kind enough to share it with me, so hopefully they won't mind me doing the same here.
It runs a batch file that checks for various services and apps etc.
Great procedure, will hopefully save me lots of time. Just wondering if anyone has an updated version that accounts for newer roles (i.e. Exchange 2010, etc...)
just relying on the EXE being on a machine dosen't really work as in we did it for exchange assuming store.exe would only be on exchange servers. while this was correct it picked up other servers that weren't actually exchange servers turning 65 real exchange box's to 165. so we had to be alot smarter about it than that.
I just found this and it has totally changed the way we are going to be managing our systems. This is nothing short of Awesomesauce.!!!
Since I started using the Policy Management I have been doing something similar and created a custom field called "MachineRole" that I can populate with predetermined Role Names. I then made a set of script one primary that detect if the machine has a windows OS and then check if it is a server or workstation OS and applies the WinWS for Workstations and WinSV to the "MachineRole" so that I know that this script has been executed against the machine.
My next phase will also include FSMO roles for domain controllers.
It also looks for a range of things such as Backup, Mail, Database, Web software etc. The same script also populates other custom fields such as "OS Install Date", "OS Version", "Default Domain" and common application (Adobe Flash, Reader, Java, Antivirus Software etc...) versions. The "OS Version" information funny enough is a Database View (#vMachine.OsInfo#) but I had to put it into a custom field as it was missing from the fields you could use in the aggregate table reporting.
The nice thing about all of this that is works well together with the KPM as you have a base policy that applies the audit procedures that fill out the custom fields for you and then you have other policies that uses these custom fields via Views I made to apply monitoring and other audit scripts.
I have one other custom field that is coming in very handy and that is the "MachineSLA" Using either the Audit Module or Agent Procedures I set the SLA type for machines and depending on SLA levels they will get Microsoft and Common apps updates pushed out to them.
HardKnox - I've gone for a very similar idea in regards to SLA type. It is very useful! Again, I've used Agent Procedures to set the custom field to the different SLAs, but I've also created policies that apply those agent procedures, therefore I just have to drop the SLA policy onto the machine group and it automatically applies the procedures to present and future machines in that group.
I've also therefore got a policy for "No SLA", and that clears the field - I apply that to everything else, such as home user's machine groups and ex-clients etc...
@Simon Burbidge Great minds think alike I thought about leaving the No SLA's empty but then I decided it might be difficult to pickup machines that got missed by the Policies that auto set the SLA levels so I ended up marking them with "NONE" instead this way I can use a view filter to find machines that may not have picked up by the SLA policy.