Windows Event Log - .evtx file import - Foriegn AD Domain

[dsctm3]

Hello,

Hoping to get a hint on where to go with this;

Use Case: I am attempting to import files from a exported .evtx file from a external Windows host as per: 

Splunk Docs for Importing Windows Event Log Files

The inputs.conf has been written close to the following.

[monitor://D:\SplunkLogImport\awesome_hostname\preprocess-winevt\*.evtx]
disabled = 0
sourcetype = preprocess-winevt
host = awesome_hostname
index = awesome_index
crcSalt = <SOURCE>
move_policy = sinkhole
evt_resolve_ad_obj = 0

The challenge here is the logs are from a server in another domain from another network entirely and I have no access to a domain controller.

As per: 
Splunk Docs for Monitor Windows EventLog Data 

I am recieving an error (as expected) but I'm not seeing any data come in.  I am not concerned with having all the data resolved and seeking to simply input this data.   

Question: Any thoughts on how to blindly import the event logs knowing full well we're not going to get SID/GID object resolution?  What is required to tell the forwarder not to bind to the domain?  I've attempted  the following with no results.

evt_resolve_ad_obj = 0

I would appreciate any guidance that may exist on this subject.

Details:
Host is running Splunk Universal Forwarder v 7.3 on Windows 2012.  Source data is from a Windows 2008 R2 server. 

The Error: (thousands of these)
INFO WinEventLogChannel - WinEventLogChannel::getEventsNew (2000): No bindToDc

[dsctm3 · Accepted solution]

So I found the solution, and as usual "It was dumb"

The resolution was that the hostname field was ignored by the input for some reason and the data got processed as the actual hostname of the host, not the name I gave it.   When I search for the actual hostname the logs have been ingested despite the warning about DC binds.

I suppose when you use that sourcetype Splunk ingests the data and runs it through the TA as it came from a native forwarder.  I suspect some of the data might be missing, but I'm willing to accept that given the lack of resolution.

Marking this solved for now.