1. Ensure that the Data Import Directory on both the Batch Processing Server and Web Application Server are valid.

On the Batch Processing Server, this should refer to a location on the device.

On the Web Application Server, this should refer to a file-share mapped to the same location on the Batch Processing Server.

This is specified within the Registry, as follows: [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ManageSoft Corp\ManageSoft\Compliance\CurrentVersion] - DataImportDirectory value

1. Ensure your Service Account has read/write access to this location from both devices - the Web Application Server and the Batch Processing Server itself.
1. This is most easily established from right-clicking within this location in Windows Explorer, then navigating to Properties > Security > Advanced > Effective Access, selecting a user or relevant Security Group, then choosing 'view effective access'
2. If these locations are valid and accessible, confirm whether, when PO Upload is attempted, the uploaded data appears within the DataImportDirectory location - a data CSV file should be generated, regardless as to whether incoming data is .XLS or .CSV format
3. Ensure that communication to the Microsoft Message Queuing (MSMQ) Queue is possible between the Web Application Server and the Batch Processing Server
1. When a PO data upload task occurs, the fnmsbatchprocessincoming messaging queue should receive a message to upload this PO data - On the Batch Processing Server, in Computer Management, navigate to Services and Applications > Message Queuing > Private Queues > FNMSBatchProcessIncoming
2. This message is then processed into a Task for the Batch Processor, and should be recorded within the BatchProcessScheduler logging on our Batch Processing Server - ProgramData\Flexera Software\Compliance\Logging\BatchProcessScheduler\BatchProcessScheduler.log
4. If there's no incoming tasks being recorded within the BatchProcessScheduler, test whether MSMQ communication is possible for the relevant service account
1. On the Batch Processing Server, pause the Batch Process Scheduler Windows Service
2. Next, on the Web Application Server in an Administrator Powershell Command Prompt as our service account, run :
   Send-MsmqQueue -Name "FormatName:DIRECT=OS:<batch processor server> \private$\fnmsBatchProcessIncoming" -Body "testmessage"
3. In our fnmsbatchprocessincoming queue on the Batch Processing Server, do we note our incoming message with body 'testmessage' ?
5. If we don't note incoming MSMQ traffic, ensure the necessary ports for MSMQ Communication are open bidirectionally for your version of MSMQ, note Microsoft's documentation here:
   https://support.microsoft.com/en-us/help/178517/tcp-ports-udp-ports-and-rpc-ports-that-are-used-by-message-queuing
1. This can be easily tested via telnet - telnet <devicename> <port> - from the Command Prompt on both the Batch Processing Server and Web Application Server - if there's connection failed from Batch Processing Server to Web Application Server or vice versa, this suggests blocked traffic in that direction
2. This could also be identified using netstat -a from a Command Prompt, which should return all ports currently listening for incoming communication
6. From the BatchProcessScheduler, we should then note the Task being processed within BatchProcessor - tasks are uptaken from the BatchProcessScheduler, and a success-code returned to it:
   ProgramData\Flexera Software\Compliance\Logging\BatchprocessScheduler\BatchProcessor.log
7. The BatchProcessScheduler and BatchProcessor logs should refer to a Task GUID here - it's then possible to confirm the status of this task in the BatchProcessExecution database table as follows:
   SELECT * FROM BatchProcessExecution WHERE GUID LIKE '%The GUID reported in the BatchProcess and Scheduler logs%'