1. Simple authoring experience. You can create either single URL tests or multi-step transactions using Visual Studio Web Performance Tests. Select from up to 16 locations to run availability tests. Can select the alerting criteria in the same dialog

2. After configuring you should see test result data flowing in 10-15 minutes. There are various aggregations which are done on raw results. You can see aggregated availability and response time for application or monitor

3. Once you determine something is failing you can drilldown to individual results to see a scatter graph

6. A Simple click on any "red x" shows the full test result to pinpoint which step within your transaction failed

7. You can also download the result right from the portal and open in Visual Studio to see raw requests/responses for each step

8. Lastly there are cool dashboards to visualize availability metrics

Once you go to Configure Endpoint Monitoring page from the Dashboard enter in your service endpoint URLs and choose some locations (8 worldwide locations are currently supported):

It takes about 15 - 20 mins for availability and performance data to start flowing:

You can also see the last five HTTP responses coming back from the configured endpoints.

If you have SCOM 2012 SP1 you can try GSM for 90 days.

One could also use the recently added Intellitrace Integration to further diagnose any issues based on GSM Alerts.

SC 2012 SP1 Beta has enabled various DevOps scenarios. For more information read about GSM on the OM Team blog.

With the release of System Center 2012 SP1 Beta, Global Service Monitor now supports new functionality of being able to run Visual Studio authored Web Performance Tests. This capability adds support for most requested features customers have asked for since we shipped GSM Customer Preview:

1.       Ability to do multi-step synthetic transactions

2.       Support for authenticated transactions within multi-step tests.

Sample

 Assume you are building a DinnerNow style app. The screenshot below shows the sample dinner ordering app with restaurant search capability.

With Visual Studio Ultimate you can create a Web Performance Web Test which would look like below. Here we have a couple of search transactions with sample data and validating that the response has valid search results.

In Visual Studio you can add various validation rules to this multistep transaction including Find Text, Response Time Goal and Response URL. Once the test is validated in your Visual Studio environment, developers can provide the same DinnerNow.webtest to Ops who can plug it into System Center Operations Manager 2012 like seen below. (There are some restrictions around ThinkTime and such which GSM doesn't allow)

Above we have configured GSM to run and monitor the DinnerNow.webtest from four locations (London, Zurich, Miami and Sydney). And there you have it -- Good from London/Sydney, but the webtest is failing from Miami/Zurich.

Each failure should trigger an Alert in the SCOM2012 Console which describes the reason for failure:

IpcServerChannel by default creates pipes in exclusive mode (no other process can listen on the same pipe name). There is a known issue with pipes -- that if there is a client side handle open to a now defunct server pipe, no further server instances are possible till a timeout cleans up the client side handles.

You can work around this issue by setting exclusiveAddressUse="false" on the server channel config. Be aware of the implications though -- any other process can start listening on the same pipe as your server. Hopefully this issue will get resolved in future releases.

The issue gets hard to diagnose for the event case, since there is not indication that the server failed to raise an event on the client.

Thanks

1. IPCChannel: A new channel based on named pipes form x-process (same machine) communication. Its more secure and performant than the previous best performer the tcp / binary channel.

2. Authentication / Authorization Support: IPC and TCP channels now have inbuilt support for authentication (identification / impersonation) and authorization. This removes the use of custom security sinks.

3. Timeout on TcpChannel: This was one of the pain points before. Now the client can specify a timeout on the tcp channel to avoid deadlocks

4. IPv6  support: Tcp and HTTP channels now are ipv6 aware

5. Better NLB support: By making the client side connection cache configurable, earlier issues with NLB and sticky connections has been eliminated.

As far as binary serialization goes the new big feature is version tolerant serialization which allows type versioning fidelity.