In Exchange 2016, to collect the Admin Audit logs, it runs a similar script to 2010
which really just does this in a nutshell :
# Retrieve Records from the LastSeen date
$Records = Search-AdminAuditLog -StartDate $LastSeen -EndDate (Get-Date)
$RecordLast = $LastSeen
However, as we run splunk under the localsystem account, it doesn't have rights and logs a variety of errors including :
10:18:18.481 -0500 ERROR ExecProcessor - message from ""C:\Program Files\SplunkUniversalForwarder\etc\apps\TA-Exchange-ClientAccess\bin\exchangepowershell.cmd" v15 read-audit-logs20102013.ps1" Search-AdminAuditLog : Object reference not set to an instance of an object.
The app log contains
WARNING: An unexpected error has occurred and a Watson dump is being generated: Object reference not set to an instance of an object.
How do you configure splunk for Exchange 2016 to have enough permissions when it runs under that local system account to access the admin audit logs and more annoyingly why did it work in Exchange 2010 when it ran under the same local system account.
You need to setup the splunk service in windows to run as a domain service account on the exchange server.
Then assign that domain user account the relevant role within exchange server.
hope this helps.
I'm having issues with this also. But I'm running splunk service, with a domain service account.
What relevant roles we need to give to that domain account?
Did you get anywhere with this? Because i am also facing this issue.
First of all it is required to run the Splunk Forwarder Server with a Domain Account and set the correct permissions in Exchange for this account. This was already stated in previous answers.
I think i've found a workaround for the Search-AdminAuditLog issue. The problem is somehow related to the way the exchange PowerShell snap-ins are loaded.
In the Exchange TAs the Snap-Ins are loaded with the -PSConsoleFile "%Exchangepath%\bin\exshell.psc1" Parameter of PowerShell.exe
It seems that if you load the exchange cmdlets this way especially the Search-AdminAuditLog cmdlet is not working as expected.
The only way I’ve found to mitigate this behaivior is to load the exchange snaps-in the correct way. To do this you have to modify the read-audit-logs20102013.ps1 and the read-mailbox-audit-logs20102013.ps1 in the Exchange TAs. You must add the following lines at the beginning of the script:
$CallEMS = ". '$env:ExchangeInstallPath\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto -ClientApplication:ManagementShell "
$null = Invoke-Expression $CallEMS
Additionally, to prevent the start-up output of the Exchange Cmdlets are logged to Splunk you have to modify the following files:
In the Exchange Installation Directory modify the following files:
"C:\Program Files\Microsoft\Exchange Server\V15\Bin\ConnectFunctions.ps1"
"C:\Program Files\Microsoft\Exchange Server\V15\Bin\CommonConnectFunctions.ps1"
"C:\Program Files\Microsoft\Exchange Server\V15\Bin\RemoteExchange.ps1"
Search for lines starting with set-variable VerbosePreference and comment them out!
After that you will receive the correct log information.
I know that’s a little bit brutal, but it will work.
The suggestion mentioned above did not work for me. I had to do the following:
1) I found it necessary to edit the read-audit-logs20102013.ps1 and the read-mailbox-audit-logs20102013.ps1 scripts with
$SessionUri = "http://" + ([System.Net.Dns]::GetHostByName(($env:computerName))).Hostname + "/Powershell/" $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri $SessionUri -Authentication Kerberos Import-PSSession $Session -AllowClobber # Add the remove session to the end of the script Remove-PSSession $Session
2) I could not write to logs nor access various logs, so found it necessary to add the service account running splunk to the Exchange Server Administrators group.
3) Found in the splunkd.log "Get-InboxRule : You must provide a value for this property". Adding a mailbox to the service account fixed this issue.
4) Found in the splunkd.log "Get-MailboxStatistics : Failed to commit the change on object "dbname" because access is denied." Adding the service account to View Only Administrators was not enough. I had to add the service account to Exchange Organization Admins.
Now that this is working I will need to pare back some rights as I do not like service accounts with so many permissions in my environment.