Considerations for Enabling Distributed Views on a CAS

So what are distributed views and why use them?

I recently posted about an issue where I was forced into enabling distributed views (DV) for my primary sites.  Technically, I enabled DV for the hardware inventory link (there are two others as well).  We had looked at using DV earlier, but even in SP1 there were issues.  But with R2, we’ve found them to be fully functional.

So what are DV?  Simply put, you tell your primary sites to keep client data instead of replicating the data up to the CAS.  Normally DRS replicates data up via SQL (CM07 would copy files to in central inboxes and let SQL import that data all over again).  DRS uses a variation of the SQL Service Broker (instead of merge or transactional replication) to copy this data back to a primary.  But for 3 major links you can tell the primary site just to hold onto that data and if you need it for reporting, SRS can grab that data from the primary sites on the fly.

CM accomplishes this on-the-fly generation of data via linked servers in SQL.  When you enable DV to a primary site, all of the replica groups in that link stop and a linked server is created in SQL.  The local ConfigMrg_DViewAccess group on the primary site is populated with the machine account of the CAS as well as the execution account SRS uses.

Note that if you have other users running ad hoc queries against SQL and they require client information, you’d want to put their AD group or ID into that local group.

Now think about R2 and how SRS respects RBAC.  A user wanting information about clients and he’s coming in via SRS means it’s going to entail an RBAC function to figure out what that user is permitted to see: he is simply not granted permissions to see all collections or devices but is limited to his scope.  For SRS to grab that data which is on the primary sites and not the CAS means we need to worry about constrained delegation.

Constrained delegation is where you set the machine account (CAS$) to be trusted to pass on a user’s ID via Kerberos to a child site.  Open the CM console to the CAS and look at devices and its CAS$ talking directly to the primary site to get you the data in the console.  It can do this because there is one hop from the CAS to the primary site.  But open the SRS site from a desktop which connects to the CAS and has to get data from the primary and you’re making 2 hops and Kerberos won’t recognize you.  To make that leap you need constrained delegation.

Note: the SPN on the server should match what you have granted in the image shown.

Generally, constrained delegation should work without issue.  But we found in practice that certain scenarios can break it.  For everyone.  How?  We’re thinking that anyone coming in from a non-trusted domain seems to poison the Kerberos cache giving mixed results to users.  Sometimes users will be shown an anonymous logon error instead of seeing their SRS report results.  We had a case open with Microsoft for a week on the issue and they never found the source of the failure no matter how many data dumps we gave them.  So we temporarily cheated with local SQL accounts on the linked servers.

So back to the why of when you enable DV.  We were told by the lead developer of CM that we’d be crazy not to use DV if a primary site was next to a CAS.  And so we did test that and we actually ran with it for a while. But back in SP1 there were issues and we decided to just go back to full DRS.  But what about servers not close to the CAS?

I explained previously that enabling DV saved DRS from sending 1 terabyte of hardware inventory back to the CAS.  That is a lot of data no matter how you look at it.  From a point of view, it actually makes sense to enable DV everywhere: save your network all of the replication of so much data and leave it on the primary servers.  Grab it only when you need to view it.  Heck, why isn’t it the default?  Why didn’t Microsoft just have CM use DV all the time?  The answer is that there is a bit of a cost.

Reports are obviously slower because the primary sites are not close and have to run the query SRS wants locally and then send the data across the WAN.  That doesn’t give the best experience to the end user.  But it gets worse.  We found that if we simply ran a query directly to each primary instead of going through the CAS, reports would run even faster.  Microsoft has yet to explain why, though they are looking into an answer for us.  I suspect that answer is going be the explanation for why DV isn’t enabled by default.  That reports are just going to be slower this way.

That isn’t all bad.  Recall that we can tell SRS to run reports on a schedule and cache the results when we want it to.  So if you set a report to run at 8am and a user wants that data off SRS at 9am, it can send the 8am results back nearly instantly to the user.  There is even a benefit here in that the user isn’t able to pound on the server by running the report often.  You get full control via SRS on how long that cache is maintained and how often SRS should just run the report in the 1^st place.

And of course, this means extra work on your part to find the most commonly used reports and start setting them up for schedules in SRS.  That’s work.  Most admins will just take a pass and let the SRS user wait.  I’d caution against that for one reason only:  managers and execs tend to think a report is a reflection of how fast CM is.  A slow report must mean CM is on its last legs.  Better go find a new product!  So you’d really better consider some schedules on common reports.

Key takeaways here are (1^st don’t setup a CAS) that if you have a primary next to the CAS, you might very well want to enable DV for one or all replication links and that if you do so, make sure your SPNs are cleanly setup and enable constrained delegation.  And what that local DV group on the primary as you might need to add other users who run CM queries.  Finally, the recommendation is that you enable DV on a primary very close to the CAS to help speed those reports, but if your WAN links are fast enough like ours are, it does work if you enable it on others too.

Also note that disabling a replication link means you're going to suddenly have a lot of data replicating all at once to your CAS so keep that in mind before enabling DV in the 1st place or deciding you want to abandon them.