Configuring Cisco WebEx Meeting Server to work with ADFS 2.0+

Fantastically useful set of instructions! If only Cisco’s own docs were this good…

Digital Glue

Like so many other things I’ve written about, this is another example of where I was unable to find a solid set of instructions online about how to do something and had to assemble a working solution from a number of fragments spread across vendor-provided information, blog posts and cries for help posted in online forum threads.  Hopefully this can spare at least a few others from having to go through the same thing.

This procedure has been used to create a system that works on the “first try” so I know that it works.  It’s possible that this could be further refined with some additional testing.

This post is targeted to the on-premise version of the Cisco WebEx meeting server, not the hosted (SaaS) version.  I believe that most of what is here should be applicable to the hosted version but there are apparently some differences in the configuration…

View original post 1,227 more words

Clearing up Event 36887 – Schannel The following fatal alert was received: 48

event36887-general

Schannel errors in Event Viewer tend to be really unhelpful.  From MSDN, Error 48 indicates TLS1_ALERT_UNKNOWN_CA  SEC_E_UNTRUSTED_ROOT  0x80090325 so most likely due to a self-signed, or internal CA signed certificate on the host in question.  But it doesn’t indicate which client computer is triggering the error.

However, you can get fairly precise time out of the XML view under the details tab (TimeCreated SystemTime gives the time with lots of decimal places making it way easier to find the offending traffic in a network capture.

event36887-details-xml

To find it in Wireshark, change the Time Display Format to  “Date and Time of Day” in the View Menu (Ctrl+Alt+1) and filter by “ssl”  The timestamps aren’t identical (plus the event log entry isn’t adjusted to the local timezone), but it’s close enough that you shouldn’t have trouble finding it.  The particular traffic I was seeing looked like this.

2014-06-11 12:00:25.774832 192.168.1.100 192.168.1.10 TLSv1 73 Alert (Level: Fatal, Description: Unknown CA)

The first IP above (192.168.1.100) is the remote client which is triggering the issue.  The second IP (192.168.1.10) is the local machine.  Then just had to sort out adding the internal CA cert to the client machine. Fixed!

Why are my LUNs offline because of policy?

Here’s something I’ve been seeing off and on since Exchange 2007.  After a reboot, The LUNs presented off the SAN sometimes appear in Disk Management with the note “The disk is offline because of policy set by an administrator” and you end up needing to manually online each disk.

There are a number of blog posts and such indicating that you need to change the SAN Policy of the server.  The default being “Offline Shared” on Enterprise and Datacenter editions of Windows Server.

The recommendation of these posts being to set the san policy to “Online All” to solve the problem.  This done as prescribed by http://technet.microsoft.com/en-us/library/gg252636.aspx.

diskpart
san
san policy=OnlineAll

After a reboot I would find that the problem persisted, the volumes would still show as offline with the same note about policy.  What wasn’t obvious from all those posts was that each disk has its own registry bit indicating that each disk has it’s own setting related to san policy which is apparently set when the disk is discovered. The values are described below.

  VDS_SP_UNKNOWN         = 0x0
  VDS_SP_ONLINE          = 0x1
  VDS_SP_OFFLINE_SHARED  = 0x2
  VDS_SP_OFFLINE         = 0x3

1,2 and 3 are somewhat obvious, but 0, VDS_SP_UNKOWN seems to indicate that for that disk, the value is undefined so to speak and that it follows the system san policy.

So it appears that in my case, with the default at Offline Shared, disks inherit that setting and regardless of what the system san policy is set to afterward, the disk remembers Offline Shared.

Found another KB article which points out that fact AND includes a quick powershell script to fix it.  http://support.microsoft.com/kb/2849097

You’ve got to dig out the string indicating your vendor from the registry, but that’s easy to find under HKLM:\SYSTEM\CurrentControlSet\Enum\SCSI


					

The number of people who run Exchange without a DAG is mindboggling.  I’ve run into several business, running Exchange 2010/2013 which don’t use DAGs at all.  Even if there’s only one location, why?

Exchange 2013 – OWA and ECP logins fail with 500 error

exchange-2013-500-error

After troubleshooting another issue, and having one of the 2013 servers crash a few times while running diagnostics, OWA and ECP logons started showing an error.

500 Unexpected Error :( An error occurred and your request couldn’t be completed. Please try again.

Reseting IIS, restarting the servers, clearing cookies etc had no effect.

Event 4 appears in the Application log at the time of the login.

Current user: 'Example.com/Test User'
Request for URL 'https://server01.example.com:444/ecp/default.aspx(https://server01/ecp/)' failed with the following error:
System.NullReferenceException: Object reference not set to an instance of an object.
 at Microsoft.Exchange.Clients.Common.Canary15.Init(Byte[] userContextIdBinary, Byte[] timeStampBinary, String logonUniqueKey, Byte[] hashBinary, String logData)
 at Microsoft.Exchange.Clients.Common.Canary15..ctor(String logonUniqueKey)
 at Microsoft.Exchange.Clients.Common.Canary15Cookie.TryCreateFromHttpCookie(HttpCookie cookie, String logonUniqueKey, Canary15Profile profile)
 at Microsoft.Exchange.Clients.Common.Canary15Cookie.TryCreateFromHttpContext(HttpContext httpContext, String logOnUniqueKey, Canary15Profile profile)
 at Microsoft.Exchange.Management.ControlPanel.CanaryExtensions.CheckCanary15(HttpContext context, Boolean shouldRenew, String canaryName)
 at Microsoft.Exchange.Management.ControlPanel.CanaryExtensions.CheckCanary(HttpContext context)
 at Microsoft.Exchange.Management.ControlPanel.RbacModule.Application_PostAuthenticateRequest(Object sender, EventArgs e)
 at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
 at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
 at Microsoft.Exchange.Clients.Common.Canary15.Init(Byte[] userContextIdBinary, Byte[] timeStampBinary, String logonUniqueKey, Byte[] hashBinary, String logData)
 at Microsoft.Exchange.Clients.Common.Canary15..ctor(String logonUniqueKey)
 at Microsoft.Exchange.Clients.Common.Canary15Cookie.TryCreateFromHttpCookie(HttpCookie cookie, String logonUniqueKey, Canary15Profile profile)
 at Microsoft.Exchange.Clients.Common.Canary15Cookie.TryCreateFromHttpContext(HttpContext httpContext, String logOnUniqueKey, Canary15Profile profile)
 at Microsoft.Exchange.Management.ControlPanel.CanaryExtensions.CheckCanary15(HttpContext context, Boolean shouldRenew, String canaryName)
 at Microsoft.Exchange.Management.ControlPanel.CanaryExtensions.CheckCanary(HttpContext context)
 at Microsoft.Exchange.Management.ControlPanel.RbacModule.Application_PostAuthenticateRequest(Object sender, EventArgs e)
 at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
 at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

The error appears to be related to corrupt attributes in Active Directory, specifically under CN=Client Access,CN=<org name>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain>. The attribute msExchCanaryData0, or msExchCanaryData1, 2, 3, etc.  can contain bad data.

500-error-adsiedit

As always, be safe, have an AD backup you can rely on.  Then proceed to to clear the value of all the msExchCanaryData# attributes (shown above in ADSIEdit).  Then the App Pool(s) for MSExchangeECPAppPool and MSExchangeOWAAppPool need to be recycled by going into IIS Manager and right-clicking each pool, then choosing “Recycle…” At this point all was sorted out for me.

500-error-apppools

 

Found info regarding the issue on TechNet:  http://social.technet.microsoft.com/Forums/exchange/en-US/777b51ee-330d-43cc-a56e-4614d44aed7b/unable-to-access-owa-or-ecp-something-went-wrong-or-500-unexpected-error?forum=exchangesvrclients

“Failed to parse RDP configuration” when using Remote Desktop App

error-failed-to-parse

Found a not so obvious bug with the Remote Desktop App (iOS, Android and MacOS) when launching apps from the Remote Resources list.  Remote Resources is a representation of the RemoteApps published on a Remote Desktop Web Access server to which you’re connected.  It’s simple and generally works nicely, most of the time.

As in the screenshot above tapping Calc 1.0 resulted in the “Error Failed to parse RDP configuration” box that popped up on this iPad.  This error only appears in the App, and only when selecting an application from within the App.  If you were to use Safari to visit the same URL as entered in Remote Resources, you can tap the icon in the browser, which then gives the option of opening it in the RD App which works fine.

The cause in this case was a space in the alias of the published RemoteApp. The application which we were trying to publish had a space in the name of the executable (e.g. “calc 1.0.exe) so the 2008R2 version of RemoteApp Manager defaulted the alias to “calc 1.0” when it was published.

rdp_broken

Editing the alias to remove the space (e.g. alias = “calc1.0”) fixes the issue.
rdp_works


You can demonstrate the issue if you change the properties of an existing RemoteApp, by adding a space in the alias.