Zach Bonham's questions

SCOM supports putting discreet objects/classes/targets into maintenance mode. This gives a very fine control over what objects/classes/targets have alerts forwarded or not.

Unfortunately, behaviorally, our operations team doesn't want that level of control.

Behaviorally they want to put the entire server, or groups of servers, into maintenance mode. Where "maintenance mode" means no alerting of any kind. Period. Fin.

Today, we come close, by putting WindowsComputer and HealthService (which also seems to cover Agent). Putting those objects into maintenance mode allows us to do application deployments (service stops, etc) and anything requiring a reboot.

However, we still get occasional alerts from objects in either like the Dell MP or BizTalk MP. Alerts that don't tend to target WindowsComputer, or anything in its inheritance chain(?).

We tried putting Entity object/class/target into maintenance mode but this seemed to send the RMS server into a tizzy. e.g. If we made 50 requests, for 50 different servers, maybe 1 in 5 would actually be placed into maintenance mode. The remainder would be ignored.

We are using the SCOM API via Power Shell, or the SCOM SDK object model, to put things into maintenance mode.

Is there a recommended way to put a server, and all its contained objects, into maintenance mode, reliably?

Is there something our team should be considering on why we don't want to put everything into maintenance mode?

One of the biggest problems we have in automating application deployments is the idea that running IIS AppPools and Windows Services under domain service accounts is a 'best practice'. Unfortunately, this best practice sometimes causes deployment headaches in that either we need to provision a new domain level service account quickly, or once we have the account, we now need to manage the account credentials.

I had a great conversation about not making domain level service accounts a requirement and effectively taking one of two approaches:

• Secure at the node level using machine account(domain\machine$) and add the node to appropriate ActiveDirectory/Sql groups/roles
• Create local app specific accounts on each machine (machine\myapp) and add that account to appropriate ActiveDirectory/Sql groups/roles (the password here can change per deployment, it doesn't need to be stored)

In both cases, it seems that its easier to manage either adding an account to appropriate group/role, or even stand up new, local account, than it is to have to provision a new domain level account and manage those credentials.

This would hopefully ease the management burden on ActiveDirectory, Sql Server and Operations teams as there would be no more password management.

We've not actually been able to implement this in practice yet. I am coming from a development background, so I'm curious as to how many ways this approach could go wrong? Can we really get rid of domain level service accounts with this direction?

I'd appreciate any thoughts from anyone who has taken this path!

Thanks!

Zach

UPDATE

Previously, since the application teams did not want to store passwords for service accounts, and we really didn't care what they were (should we?), we provided our ActiveDirectory team with a utility that created a hash of the password. So, when we needed a service account, we'd submit the request and they would respond with the hashed password.

In our deployment scripts (which the app team owned) any where we used a password, we actually used the hash. The deployment framework knew how to decode that hash on the fly when creating assets.

I am coming from an application development perspective (my day job) and not an infrastructure, or operations, perspective, so if this is a completely inane question, please let me know!

We have proxies in front of our application servers and this has typically served us well. This (hardware/software) proxy provides an abstracted endpoint (in addition to other services, such as load balancing/distribution) so that our clients always know how to connect.

Does anyone have any experience putting a proxy between application servers and the the database?

Seems like someone has got to be doing this, especially in hosting provider, or cloud space, but when I've talked to our (enterprise) infrastructure teams they just say 'no' though I'm still struggling to understand why.

I don't understand if due to the extra layer of abstraction in front of the database this causes functional or performance issues, or just plain makes it harder to trouble shoot when things go wrong.

Can anyone share thoughts, experiences, or resources in this area? I would greatly appreciate it!

Thanks!

Z