How to integration Microsoft Exchange on Splunk Without installing UF on Exchange Host?

[AceX]

How to integrate Microsoft Exchange on Splunk without installing  a universal forwarder that hon the Exchange Server host.  Based on add on official documentation https://docs.splunk.com/Documentation/MSExchange/4.0.4/DeployMSX/AboutSplunkforMicrosoftExchange  for integration it requires UF on Exchange server host but it is not recommended and also this solution client will not like. So I need another solution to integrated without installing add on directly on Exchange host, we is there any way to send data to intermediate UF then HF?

[PickleRick]

It depends on what kind of data you want to pull from the Exchange host.

As far as I remember, the TA for Exchange contains some scripted inputs - generally those you cannot run without installing the UF on the Exchange server (I suppose _maybe_ for some of them if you bent over backwards you could try to launch them remotely via something like Invoke-Command but it will require customisation of the existing add-on and further maintenance will be on you.

If you want events from EventLog, you can use WEF (I've had some relatively successful installations running WEF and UF on the WEF collector; they might have some performance problems at some point but up to that point they run quite well).

If you want contents of the log files... you can share them over the network but it can backfire. Firstly, the UF on the remote computer (which would access those events over the network) would have to run under a domain account and have permission to access those exported logs. That might be tricky if you normally don't run UF from a domain account but is a relatively normal task for a typical domain admin. The second problem, which might bite you in your behind at some point is that since Exchange produces a lot of logs (by default one log per hour if I remember correctly) and doesn't delete the old ones, the number of logs which Splunk has to keep track of grows quickly. And  checking status of remote logs has much much higher latency than local operations. So restarting such UF which monitors Exchange logs over the network might lead - in border cases - to several hours of pause in logs ingestion. I had a customer who precisely because of this problem copied files from exchange server to another server by means of a script and then UF would pick them up from that destination server.

So while you can try to ingest the logs from Exchange without using the UF, the method with installing UF locally on the machine is the most convenient and best performing one.

[AceX]

How to integrate the first solution is there any documentation and which add on to us TA for windows and which events needs to be selected? If there is documentation please send

[PickleRick]

I don't think there are any ready-made docs about all this. The default installation and configuration instructions for the Exchange TAs assume doing it "the blessed way" - installing UFs on the servers, ingesting the data locally with those UFs. If you want to change the architecture, it's up to you.

I already gave you some hints but the resulting setup will depend on what kinds of data you want to ingest, which method of reaching for the data you choose and so on.

As a side note, if you want to ingest eventlog data, there are generally four possible ways of doing so. In order of preference/feasibility/sensibleness/practicality.

1. Native ingestion with UF installed directly on the source host - this is the default recommended method of injecting windows eventlog data.

2. Using WEF to forward windows events to a collector node and ingesting events from there with a UF - this adds complexity to your environment, can be tricky to set up in a domainless environment, you can hit some performance limits (the same limits you can hit with local ingestion but it's much more likely with a WEF collector which receives data from several other nodes).

3. Using UF with WMI input which calls external server(s) and queries event logs there - this is awful to set up, WMI is not very efficient, requires "loosening" your security stance so that the UF node can reach other servers with WMI... Generally - don't use it unless you can't use either of the previous methods.

4. The absolutely worst idea - pull your events from eventlogs with a third party tool, and forward it another way to Splunk - this not only mixes different solutions needlessly in one environment and adds a lot of complexity and raises maintenance burden significantly, it also usually produces data in a format which is not easily parseable by Splunk (or even not reasonably parseable at all because the format is ambiguous). The only tool I've seen so far which looked as if it could produce logs which could be parsed with Splunk's standard TA-windows, was NX Log. But the docs stated that sending logs formatted like the original XML event was available only in premium paid version which I didn't have access to - the free one couldn't do that. So I'm listing this only as a remote possibility. It wouldn't solve your problem anyway because that also needs a piece of software, just another one, on the source server.

So long story short - for windows eventlogs, your best bet would probably be to set up WEF in your environment.

For scripts - that will be tricky.

For files - you can try sharing the files over the network and accessing them "directly" from a remote UF but as I wrote before you can hit some issues.

You're trying to do something which - while I can understand the reasons - is still a non-standard way and requires careful planning and tailoring the solution to your particular environment. That's what you typically pay your local experienced Splunk Partner to do.

[livehybrid]

Hi @AceX 

What makes you think its not recommended to install a UF on an exchange server? This is the documented reliable way to get MS Exchange logs into Splunk as per the docs.

There is a chance you can access the data through WMI from a separate external host but this introduces further security risks, along with likely incompatibility issues.

🌟 Did this answer help you? If so, please consider:

• Adding karma to show it was useful

• Marking it as the solution if it resolved your issue

• Commenting if you need any clarification

Your feedback encourages the volunteers in this community to continue contributing.

[AceX]

I will never install Universal forwarder on my critical infrastructure hosts like domain controller or exchange hosts etc, and if there is way to create additional virtual machine and there install UF and get data through VMI it will be solution for me. Like Active Directory I integrated this way not installed UF directly on DCs. So if its possible to get that data using VMI, please send me documentation and you will get karma and your solution will be accepted.

[PickleRick]

@livehybrid It's not unusual to meet such requirements at customer's site. It's often not due to technical reasons but caused either by politics (interdepartamential tensions for example when one team is responsible for Splunk and another team manages the mail infrastructure) or by the fact that some solutions are maintained and supported by external company and introducing another element (in this case - the UF) to said solution/infrastructure might be grounds for said supplier trying to undermine the contractual obligations due to a component not provided/maintained/installed/etc. by them.

So while I do agree that the UF directly on Exchange server would most probably be the best solution from the Splunk infrastructure point of view, it's sometimes simply not politicly viable.

[AceX]

I want to mention that you described the situation great way, so the question is what to do in situation by politics or by companies clients or customer's policy you can not directly install UF on exchange host does Splunk suggests another solution or another add on for parsing data, As I said if its possible using another virtual machine install Universal forwarder on it than say exchange to send data to the vm it actually preferred for me. 

[AceX]

Each company have their own policy, so just you can not say your client "Hey look it is the only one solution if there is other way to integrated, I your company wants to integrate Exchange but it is not best practice or Exchange or DCs is critical servers for them so you can not install UF directly there, some person mentioned VMI so it will be great To get Mailbox data using another VM and UF installed on it. So guys if you know solution like this, it will be great for me.

[livehybrid]

@PickleRick I totally agree, however statements like "UF on Exchange server host but it is not recommended" these days get picked up by google AI results as concrete answers and I'm trying to understand if this is an opinion or something that is a documented recommendation. If an end-client has a preference then that is another matter, but also good to understand the rationale behind these decision as trying to work around them can introduce risks of their own.

[PickleRick]

OK. I would just blame it on the fact that @AceX is probably not a native English speaker (neither am I ;-)) so probably the statement turned out to sound a bit different than intended (at least I choose to interpret it that way).

[AceX]

Let's exclude AI or some script kiddos Experts, each company has their own policy, and if based on this policy You can not install any additional softwares  on critical servers so it actually means so can not 🙂 And I am here to find another solution except installing UF directly on Exchange host. Thanks