XMA/ECMA call-based export does not support multi-valued attribute-level deltas

Here's a seemingly undocumented feature of the XMA/ECMA. I've got an XMA that's doing call-based exports, and I've noticed that it doesn't contain atomic add & remove operations at the item level in a multi-valued attribute list. Instead, it's giving me the entire list of items in the object's current state.

This is interesting, because when I look at the pending export in the sync engine, I see the atomic operations.

When I examine the arguments passed into the ExportEntry API call, I see a Replace at the top level, but nothing on the multi-valued attribute (member in this case).

[ExportEntry]

modificationType:   Replace      
changedAttributes:  member
csentry:            [Microsoft.MetadirectoryServices.Impl.CSEntryMAImpl] CS Role CN=ROLE-CRM-Test1
DN:                 CN=ROLE-CRM-Test1
ObjectClass:        Microsoft.MetadirectoryServices.Impl.GenericValueCollection
ObjectType:         Role         
RDN:                CN=ROLE-CRM-Test1
displayName         [String]            ROLE-CRM-Test1
member              [Reference]         CN=007528
                                     CN=dev.userA
                                     CN=dev.userB
                                     CN=dev.userC
                                     CN=dev.userD
                                     CN=dev.userE
                                     CN=dev.userF

(Wouldn't it be nice if you could just serialize the CSEntry object?)

So, I looked around on the forums, and sure enough, Markus confirms my observation:

"If members is in the list of changed attributes, the member attribute of the CSEntry contains the most recent value for this attribute.

"If you need to determine the individual change for each member, you need to calculate this. The ECMA doesn’t provide multi-valued attribute level changes."

Rebecca Croft also informs me that not even the file-based export supports item-level deltas on multi-valued attributes.

I'd love to be proven wrong about this...

Powershell: get process ID by window name/title

Powershell is cool.

get-process | where {$_.mainwindowtitle -match "pattern"} | format-table id, name, mainwindowtitle -autosize

SSRS data processing extension, Windows integrated security, and impersonation

I've been playing around with Craig Martin's SSRS Data Processing Extension for FIM. (Great stuff; thanks for posting it, Craig!) I had to do some troubleshooting with Windows integrated security and Windows credentials stored securely on the server.

I noticed that the IDbConnection.Open method was being called as the impersonated Windows user:

2010-11-11 14:56:37,932 --4-- DEBUG [FimDataProcessingExtension.FimConnection]    

   [Microsoft.ReportingServices.DataProcessing.IDbConnection.Open] Current user info:
   Name               : TEST\joe.zamora
   IsAuthenticated    : True
   AuthenticationType : Kerberos
   ImpersonationLevel : Impersonation

However, the IDbCommand.ExecuteReader method was not run under the context of the Windows user:

2010-11-11 14:56:37,934 --4-- DEBUG [FimDataProcessingExtension.FimConnection]    

   [GetData] Current user info:
   Name               : TEST\svc_ssrs
   IsAuthenticated    : True
   AuthenticationType : Kerberos
   ImpersonationLevel : None

Well, turns out that this is by design. Here's the official word from Microsoft:

Impersonation and Custom Data Processing Extensions

If your custom data processing extension connects to data sources using impersonation, you must use the Open method on either the IDbConnection orIDbConnectionExtension interfaces to make the request. Alternately, you can store the user identity object (System.Security.Principal.WindowsIdentity) and then reuse it in the other data processing extension APIs.

In previous releases of Reporting Services, all custom data processing extensions were called under user impersonation. In this release, only the Open method will be called while impersonating the user. If you have an existing data processing extension that requires integrated security, you must modify your code to use the Openmethod or store the user identity object.

Thus, you should save the current Windows identity to a local variable in the IDbConnection.Open method:

if (this.integratedSecurity)
{
    this.windowsIdentity = WindowsIdentity.GetCurrent();
}

And then you can use it later in the other API calls:

private WindowsImpersonationContext impersonationContext;
internal void MaybeImpersonate()
{
    if (this.integratedSecurity)
    {
        impersonationContext = this.windowsIdentity.Impersonate();
    }
}

That'll teach me for not reading the documenation. ;)

Data source name not found and no default driver specified

Ahhh, another chance to give back to the community. It's bittersweet. It feels good to contribute, but you really go through the fire to figure out something that no one else has.

This one is an error message that I was getting from SQL Server Integration Services (SSIS). I recently inherited a package (isn't that a nice excuse :) and I switched the connection string from Windows integrated to SQL auth. Pretty standard operation, wouldn't you say? Well, I've been around the block enough to not be totally shocked when I got a few error messages:

An error occured on the SSIS Listener Microsoft.SqlServer.Dts.Runtime.Package/Connection manager "JOESPLACE\MSSQLSERVER.TEST" : SSIS Error Code DTS_E_OLEDBERROR.  An OLE DB error has occurred. Error code: 0x80004005.
An OLE DB record is available.  Source: "Microsoft OLE DB Provider for ODBC Drivers"  Hresult: 0x80004005  Description: "[Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified".

An error occured on the SSIS Listener Microsoft.SqlServer.Dts.Runtime.TaskHost/Execute SQL Task : Failed to acquire connection "JOESPLACE\MSSQLSERVER.TEMPEST". Connection may not be configured correctly or you may not have the right permissions on this connection.

An error occured while processing the file C:\temp.txt. Details: There was an error executing the SSIS package C:\test.dtsx.  Please check the event log for more information.

Okay, so there's an error in the connection string. Let the troubleshooting begin. The thing about this little guy is that he just wouldn't go away. I tried a bunch of different changes to the connection string; nothing worked.

This package is a little different because we're using a variable to specify the table. I suspected that this had something to do with it, so I tried a bunch of different things. It must have been after I switched to an existing table and then back to the table variable that it started working. I didn't know it at the time, because I was being a little sloppy with my trial-and-error.

Anyway, after I got it to work, I compared the dtsx files before and after. Then, starting with the original version, I made one change at a time until it worked. Turns out that the fix was totally a one-liner. Aaarrggghhh! ...and here it is:

<property id="5852" name="OpenRowset" dataType="System.String" state="default" isArray="false" description="Specifies the name of the database object used to open a rowset." typeConverter="" UITypeEditor="" containsID="false" expressionType="None">[dbo].[TEMPEST]</property>

In the original file, the entry was blank; that's it.

A couple more bizarre things about this problem:

• The package would run in Visual Studio, but not after being published.
• I deleted the [dbo].[TEMPEST] table and it still worked.

I meant to fix this a while back, but just now got around to it. I think the problem was actually that I was missing the driver in the connection string, just like the error message suggests. Evidently, you can't just use any old .NET connection string; it has to have the driver in it. Ugh.

Built-in SSRS 2008 Roles

I couldn't find a satisfactory permission matrix for the built-in SSRS 2008 roles, so I'm publishing one here. This is a pretty comprehensive list; you may have to maximize your browser window for this!

For completeness, I'll mention that you can manage these roles by connecting to a Reporting Services instance and browsing the Security folder.

If you connect to the database engine, you can find the permissions encapsulated in the TaskMask column of the Roles table, in the ReportServer database. I would avoid editing the permissions there.

Enjoy!

	Built-in Role	System Administrator	System User
	Description	View and modify system role assignments, system role definitions, system properties, and shared schedules.	View system properties and shared schedules.
	TaskMask	110101011	001010001
Task	Description
Manage roles	Create, view, modify and delete role definitions.	X
Manage report server security	View and modify system-wide role assignments.	X
View report server properties	View properties that apply to the report server.		X
Manage report server properties	View and modify properties that apply to the report server and to items managed by the report server.	X
View shared schedules	View a predefined schedule that has been made available for general use.		X
Manage shared schedules	Create, view, modify and delete shared schedules used to run reports or refresh a report.	X
Generate events	Provides an application with the ability to generate events within the report server namespace.
Manage jobs	View and cancel running jobs.	X
Execute Report Definitions	Start execution from report definition without publishing it to Report Server.	X	X

	Built-in Role	Browser	Content Manager	My Reports	Publisher	Report Builder
	Description	May view folders, reports and subscribe to reports.	May manage content in the Report Server. This includes folders, reports and resources.	May publish reports and linked reports; manage folders, reports and resources in a users My Reports folder.	May publish reports and linked reports to the Report Server.	May view report definitions.
	TaskMask	0010101001000100	1111111111111111	0111111111011000	0101010100001010	0010101001000101
Task	Description
Set security for individual items	View and modify security settings for reports, folders, resources, and shared data sources.		X
Create linked reports	Create linked reports and publish them to a report server folder.		X	X	X
View reports	View reports and linked reports in the folder hierarchy; view report history snapshots and report properties.	X	X	X		X
Manage reports	Create, and delete reports; and modify report properties.		X	X	X
View resources	View resources in the folder hierarchy; and view resource properties.	X	X	X		X
Manage resources	Create, modify and delete resources, and modify resource properties.		X	X	X
View folders	View folder items in the folder hierarchy; and view folder properties.	X	X	X		X
Manage folders	Create, view and delete folders; and view and modify folder properties.		X	X	X
Manage report history	Create, view, and delete report history snapshots; and modify report history properties.		X	X
Manage individual subscriptions	Each user can create, view, modify and delete subscriptions that he or she owns.	X	X	X		X
Manage all subscriptions	View, modify, and delete any subscription regardless of who owns the subscription.		X
View data sources	View shared data source items in the folder hierarchy; and view data source properties.		X	X
Manage data sources	Create and delete shared data source items; and modify data source properties.		X	X	X
View models	View models in the folder hierarchy, use models as data sources for a report, and run queries against the model to retrieve data.	X	X			X
Manage models	Create, view, and delete models; and view and modify model properties.		X		X
Consume reports	Reads report definitions		X			X

SQL Server 2008 Reporting Services RS.EXE Supporting Forms Authentication

I've decided to expand the scope of my blog to more than just Identity Management. Recently, I've been submerged in the BI space, and since I'm not sure when I'll resurface, I'd like to contribute some of the cool stuff I've been doing back to the community.

I'm currently working on a scale-out deployment of SSRS that uses Forms authentication. Everything is working well with the security extension, and now we're focusing on moving everything into Stage. Good time for the scripting utility, rs.exe, right? Well, if you didn't already know, rs.exe isn't supported with Forms authentication. Wow, what a bummer.

What's more, I can't use the RSScripter, which is a very cool and useful app for generating scripts for rs.exe.

So, what do I do? I could write my own utility. We already have a web service client to integrate SSRS with an in-house app. I would just need to add a bunch of management features to it... and add commands to extract and load... and make it generic enough to reuse... and then maintain it. Nah, that sounds like a lot of work. Let's just use .NET Reflector on the original rs.exe app!

I've reassembled rs.exe with the ability to preserve the RS authentication cookie, which is required with Forms authentication. Hopefully someone out there finds this useful!

http://rs1.codeplex.com/

BTW, the RSScripter also doesn't support Forms authentication, because rs.exe doesn't, and RSScripter is dependent on rs.exe. Leave me a comment if you need a version of RSScripter that works with Forms auth.

Good luck!

Update 2011-06-22: RS1.EXE works with SSRS 2008 R2 with SP1

Compilation failed. Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.

If you've recently upgraded FIM to RTM and you're getting the following error message when you compile your custom activities, then you probably need to copy the new Microsoft.IdentityManagement libraries out of the GAC.

"Compilation failed. Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information."

copy /y C:\Windows\assembly\GAC_MSIL\Microsoft.IdentityManagement.WFExtensionInterfaces\4.0.2592.0__31bf3856ad364e35\Microsoft.IdentityManagement.WFExtensionInterfaces.dll .

copy /y C:\Windows\assembly\GAC_MSIL\Microsoft.IdentityManagement.Activities\4.0.2592.0__31bf3856ad364e35\Microsoft.IdentityManagement.Activities.dll .

copy /y C:\Windows\assembly\GAC_MSIL\Microsoft.IdentityManagement.WebUI.Controls\4.0.2592.0__31bf3856ad364e35\Microsoft.IdentityManagement.WebUI.Controls.dll .