Scheduled task for EVAPerf
Note: This information is based on a Gen 1 EVA…things are not necessarily the same with newer generations. Your mileage may vary.
If you’ve got HP EVAs as your storage platform, you’ve probably heard of EVAPerf at some time or another…
Sure, you can run EVAPerf interactively now and then to gather data on your EVAs, but what about running it as a scheduled task and keeping a month or three or more of daily output files? You can easily do that using a scheduled task on the server running Command View and the two scripts attached here. That way you actually have the data when you need it, usually when something goes wrong in your EVA environment.
The first script is a simple VBScript that deletes files older than XX days from directory YY. You specify both items and it just works. In fact, both items you need to put are in a single line in the script! The line below assumes that you’ve created a “Data” folder inside of your “EVA Performance Monitor” folder…why not. 30 days of data will be retained with this entry.
Call CleanDirectory(”C:\Program Files\Hewlett-Packard\EVA Performance Monitor\Data”, 30)
The second script is a batch file that calls the VBScript cleanup script and then actually runs the EVAPerf command. You’ll need to have done your homework first on setting friendly names and so forth on your EVAs, but your local HP storage support team should be able to assist with that if you don’t already have that done.
The second script does a few nice things for you. First of all, it automatically generates a new file name daily with date/time in the file name. Not as easy from the command line as in VBScript or Powershell, but it can be done. The script also clears the counters on the EVA and then runs the EVAPerf command. You’ll want to pay attention to make sure you edit the EVA WWN correctly, and you might even want to not clear counters. Again, up to you and local support.
Put both scripts, once you’ve edited them, in a folder named “Scripts” inside your “EVA Performance Monitor” folder and then create a scheduled task to run the batch file. The account you use to run the batch file needs to be a local admin on the server where the scripts (and Command View) are running as well as a storage administer. How you go about setting that up depends on whether or not you have your Command View server in your Active Directory domain (all new installations) or if its in a work group (older SA based installations).
Configure the scheduled task to run once daily, I’d suggest midnight local time. Then configure it to only run for 23 hours and 58 minutes. That makes sure you get a new run daily, with a new file.
Pay attention to the following lines which require editing in the batch file:
- set filename (put your EVA name in here)
- The line where counters are cleared (put your EVA name here)
- The line where the actual EVAPerf command is issued (put your EVA WWN here). Note that you may want to change what EVAPerf data you are collecting here.
Here’s a whitepaper on EVAPerf (happy reading): whitepaper
Get the scripts here…
EVAPerf.zip (1.5 KiB, 1,300 hits)
Print server migration script
We’ve got a project upcoming where we’ll be moving all of the Windows print queues from four existing print servers (they’re also file servers) to a a single print server. This is a good thing since it will get the load of having the print queues (and all of the various drivers) off of the file servers onto a dedicated server.
Migrating the 500 or so print queues is not so bad, even if done by hand to ensure that the there is only one version (the most current) of each printer driver installed. But how would one go about updating the mappings on all of the client computers? That’s a big task for any organization, especially when you get into the thousands of computers and thousands of users involved.
The attached script will do just that. It should be run as a startup script and will query the local PC to determine what network print queues it is mapped to and remap them accordingly to the new server…just change the server names and off you go.
RemapPrinters2.zip (728 bytes, 1,253 hits)
Granting permissions on Event Logs
I was asked a few days ago by our application developers to grant them read-only access to the Application logs on a couple of Web servers. Some of their Web applications write custom entries to the Application log, and they wanted to be able to connect to the Web servers via Computer Management and see those log entries.
Easy enough request…but I’ll never understand why Microsoft doesn’t allow you to configure Event Log security from the Properties dialog box like you can for literally everything else (file, folders, registry hives and keys, directory services objects, the list goes on…). No, we get stuck using SDDL (Security Descriptor Definition Language)…not exactly the funnest thing in the world.
Fortunately, you can grant permissions on the Event Logs easily enough to either well-known SIDs or even to individual groups or users. First things first…you’ll manage the security settings for the Event Logs via the CustomSD string value in the Registry. Look at the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog key. Under this key, you’ll see entries for the Application Log, Security Log, etc.
Looking at the CustomSD String key, you see the lovely SDDL entries. Joy!
So, basically, there are three parts:
- Allowing (A) or Denying (D)?
- What level of access?
- Who to?
Allowing or Denying access is pretty straight-forward.
The levels of access are as follows (and are cumulative to reach combinations):
- 1 = Read
- 2 = Write
- 4 = Clear
The last part is the SID that the permissions are being set for. This can either be a well-known SID (in that case a SID string can be used such as IU in the third to last enty in the key above or an actual SID like that seen in the last entry in the key above…or even a REAL user’s or group’s SID. Cool!
So, since I wanted to grant read access to the Application Log only for the developers, I added the following entry to the end of the CustomSD String key for the Application log. Of course, your SID values will be different!
(A;;0×1;;;S-1-5-21-1605523419-404293322-1556899496-26114)
Be sure to get all of the parts of the entry correct. That would be the opening parenthesis, the A or D, the two semi-colons, the Hexadecimal value representation of the cumulative permissions desired, three more semi-colons, the SID and lastly a closing parenthesis.
Need a quick way to get the SID for a security principal in your domain? Try the attached script file. Save it as a .VBS file and place the sAMAccountName of the security principal you’re interested in where the **SAM** placeholder is.
You can get some more information about making these changes in KB323076, and on MSDN.
getSIDv2.zip (419 bytes, 1,171 hits)
-
Translator
