Configuration Manager Report Subscription to File Share fails with "An impersonation error occurred using the security context of the current user."

Hello all,

Hard to believe it's been a year since my last blog.  Definitely a testament to how busy I've been the past year.  This blog isn't really anything that one could not find without doing a bit of research.  However, in the course of my research, the reference I found that helped me solved the problem was not in the normal location (TechNet or Docs) I expected.  Rather, it was on MSDN.  As a result, I wanted to put together a blog so the arachnids on the web could find this and make it a bit easier for others who have experienced a similar issue and could not find a reference to aide in resolving when doing a web search.

Today's blog discusses an error that was presented to me by one of my customers this past week regarding a Configuration Manager report subscription that was failing to create a CSV export on a file share.  Admittedly, I've never worked much with report subscriptions, but since its in the job description to help my customers out with issues, there you have it :)

The most common issue with any sort of failure when creating files in a file share is usually permissions.  So doing our due diligence, the first thing we did was ensure the file share permissions were set to at least Change and the NTFS permissions were set to at least Modify.  Then we validated we could actually copy files into the file share.  After we ensured this was correct, we ran the subscription and the following error persisted.

"An impersonation error occurred using the security context of the current user."

I've seen in other environments with file shares that sometimes you have to use admin share of the drive in the UNC path.  For example, \\server\share is the UNC path, but you can't get to it without using \\server\d$\share.  So, we altered the subscription to include this and still the error persisted.  The next step we did was to focus on something simple.  We created a test file share on the customer's local device where they were a local admin.  Then we altered the subscription to point the customer's local file share and used the customer's account in the subscription.  Same issue.  At this point, I'm thinking something is not right and began to start digging into our documentation.

Digging through our TechNet and Docs sites, nothing popped out for this issue.  Then, I came across this reference for Configuration Manager subscriptions on MSDN of all places:

https://msdn.microsoft.com/en-us/library/dn818160.aspx#Anchor_1

And it all made perfect sense at that point.

The Reporting Services service account controls subscription delivery and interacts with the account used for file share subscriptions. Windows security features restrict combinations of 1) the Reporting Services service account and 2) the account used for file share accounts. For example, if a built-in operating system account is used for the file share account, then the Reporting Services service account must be another service account with impersonation permissions. If an explicit file share account and password is configured, then the file share account requires the right to logon on to the computer running the Reporting Services service. If the file share account does not have the required permissions, subscriptions using the file share account will fail with an error message similar to the following:

“Failure writing file {file} : An impersonation error occurred using the security context of the current user.”

The issue boiled down to the account that was being leveraged in the report subscription did not have the local group policy setting set to allow the account to log on locally to the reporting services point site system.  That setting is found here in Local Group Policy editor:

Once the account was added here on the reporting service point site system, the subscription was able to successfully create the file on the file share.

Hope this blog helps those who experience a similar issue resolve it much quicker than it took me to aide my customer.  Until next time.

-Matt

Comments

• Anonymous
  June 19, 2018
  Thank you, Matt!