Hi was wondering if the future versions, System Center 2016? will make an easier option to "trust" a gateway in your "own" network by the us
Hi was wondering if the future versions, System Center 2016? will make an easier option to "trust" a gateway in your "own" network by the use a "proxy" program rather than use a confusing (some command line, some gui) certificate trusting system that i still haven't got my head around and you dont actually teach in your official training classes because it is too difficult. Why cant you just have a Gui prgram that just chooses a trusted gateway to use and exchange its own "trust"?
Or have the agents able to use a http/https proxy? I know plenty of other products that do this and its quite secure :)
Samuel Tegenfeldt commented
Port selection isn't really an issue, and separating monitoring traffic from "other" https (http is a no-go) usage is a good thing in my book. It's often more accepted to open 5723 from DMZ into the management domain than it is to open HTTPS. Even if you scope it to the specific management servers.
That said, the certification management is a bit weird in SCOM and should be looked into i think. It's not that hard to manage once you realize that it's just a regular client/server certificate (lot's of organizations routinely deploy these to their servers as part of their regular PKI strategy).
I also agree that installing an OMGW should be as simple as manually installing an agent. Provided the encryption is in place (the certs), it should simply plop into "Pending Management" for approval. No pre-approval from cmdline tolls you have to manually copy from an arbitrary place on the installation media, with undocumented requirements on database access and obscure (but lovely) settings like /SiteName. (Don't you dare remove /SiteName, Microsoft!)