MICROSOFT

So, this is something I’ve been waiting to write up for a while! PowerShell for macOS has been available for a while now, but what a lot of PowerCLI fans have been waiting for is to be able to use PowerCLI direct from their Mac. Today, amidst all of the noise from VMWorld, PowerCLI Core dropped as a Fling! That means that although it’s not ready for production use yet, it is ready to start testing - and I’m way more excited than I should be!

This is the first article in a series about how to build-out a simple vCAC 6 installation to a distributed model. Simple vCAC deployment In a simple installation you have the Identity Appliance, the vCAC appliance (which includes a vPostgres DB and vCenter Orchestrator instance) and an IaaS server. The distributed model still has a single Identity Appliance but clusters 2 or more vCAC appliances behind a load balancer, backed by a separate vPostgres database appliance.

I’m fairly new to SRM, but even so this one seemed like a real head-scratcher! If you happen to be using CA signed certificates on your “protected site” vCenter and “recovery site” vCenter servers, when you come to linking the two SRM sites you encounter SSLHandShake errors – basically SRM assumes you want to use certificates for authentication because you’re using signed certificates. If you use the default self-signed certificates, SRM will default to using password authentication (see SRM Authentication).

I’ve previously posted around this topic as part of another problem but having had to figure out the process again I think it’s worth re-posting a proper script for this. VMware KB 1016106 is snappily titled “ESXi/ESX hosts with visibility to RDM LUNs being used by MSCS nodes with RDMs may take a long time to boot or during LUN rescan” and describes the situation where booting ESXi (5.1 in my case) takes a huge amount of time to boot because it’s attempting to gain a SCSI reservation on an RDM disk used by MS Clustering Services.

This is my current scenario: there are two existing servers in a stand-alone array - TMG01 and TMG02, and over in a DR site there is a new server (TMG03) that is in the process of being built. To comply with DR, all 3 servers must have their configurations up to date, however there is no direct communication allowed between the two DMZs, so simply adding to the new server as an array member is not possible.

A couple of months ago I posted the first version of my SCOM 2007 R2 Daily Health Check Script - here is version 2. It’s more than a little motivated by some friendly competition with a Microsoft PFE for SCOM, hopefully you’ll agree it’s a big improvement on the last version. Updated for this version Formatting changed to make it more readable and more compatible Added “Report generated on ” to the top of the report Management Server states reported as one section Default MP check moved to beneath the Management servers Agents in pending states moved to be with the Agent health states Clarified “Unresponsive Agents” and “Agents reporting errors” Management server alerts streamlined Added top 10 alerts for the last 7 days, and added top alerters for each I’m planning to wrap in some SQL database size checks and some of the other recommendations later - I’ll post again here when that’s ready 🙂

This is every file server admin’s nightmare: hundreds of shares, thousands of folders, hundreds of thousands of files - and custom or not inherited rights on many of them. Terabytes of data that need auditing - e.g. to find customer data, or credit card information. How do you go about accessing all the data in all the trees? What about backups failing because someone removed the System account? Of course you can seize control of the folder by taking ownership and pushing down from a top level - but how do you preserve the existing Access Control Lists?

An updated version of this script has been released: https://www.definit.co.uk/2012/05/scom-2007-r2-daily-health-check-script-v2/ I’ve been working with a Microsft SCOM PFE (Premier Field Engineer) for the last few months and part of the engagement is an environment health check for the SCOM setup. Based on this Microsoft recommend a series of health checks to for the environment that should be carried out every day. This is summarised as the following: Check the health of all Management Servers and Gateways Check the RMS is not in maintenance mode Review Outstanding Alerts Review Agent’s Health Status Review Backup Status Review any Management Group Alerts Review the Pending Management status Review Database Sizes (Operations, Data warehouse, ACS) Review Volume of Alerts Review Alert Latency Document any changes  From this, there are certain aspects that can’t be automated so easily, or shouldn’t be - e.

The Test MAPI Connectivity monitor for the Exchange 2007 management pack will automatically generate a critical error for any Recovery Storage Groups you have on monitored Exchange Mailbox Roles. As these are generally temporary Storage Groups created for a recovery and then removed, you don’t want an alert - but manually adding an override for every time is not a great use of your time either. The State Change event details are as follows:

Just a quick script to set the Path Selection Policy on any LUNs on a host that do not have your target policy enabled. The script sets the server to Maintenance mode first, evacuating any VMs if you are in a full DRS automated environment. While this is not strictly necessary, it was required for my production environment just to be safe. param( [string] $vCenterServer = $(Read-Host -prompt "Enter vCenter Server Name"