I am using Windows environments for my development and testing (except from the NetApp simulator, of course, but it's registered in my Windows test domain).
When an FPolicy server application registers with a NetApp Filer storage system for FPolicy screening or monitoring, RPC over named pipes is used as the communication channel. The FPolicy server application first calls the "FP_Registration_V2" RPC method and passes it several parameters like 'opsToScreen', 'policyName', 'optionalParams', and 'smbPipeName'. The 'optionalParams' parameter is a string comprised of a computer name and domain name, for example, "\\KEVINPROD\kevinDom".
To aid in development and testing, I would like to be able to run the NetApp simulator on a virtual machine that is part of my test domain, and then run my FPolicy server application on my local machine that is part of our corporate domain (we as developers don't have rights to add the NetApp simulator to the corporate domain).
Network communication between machines in my test domain and my local development machine are fine. I have written my own RPC server and client application and can run either of them on the test machines and successfully communicate with the corresponding one on my local development machine (this required me setting up and allowing anonymous/Guest RPC connections on my local development machine, but that's no problem).
In my own RPC test applications, I specify the IP Address and named pipe name to establish the connections between the two machines (a server in my test domain and my local development machine in our corporate domain). I then make an RPC call and, using Wireshark, I can see the network traffic (on port 445).
Trying to do the same thing with the NetApp simulator doesn't work. I don't see any network traffic at all from the NetApp simulator. So, how does the NetApp simulator (and I would assume the real thing too) communicate? What I mean by that is, in my second paragraph when I talked about the 'optionalParams' parameter of the "FP_Registration_V2" RPC call, I've discovered that if I use an IP Address for the 'machine\domain' string, it doesn't work, even with a machine that is in the same test domain as the NetApp simulator. In other words, I can run my program on Server1 of my test domain and specify "\\Server1\KevinDom" as the value for the 'optionalParams' parameter and everything works just fine. I receive screening events from the NetApp simulator whenever I open or edit files. However, if I use "\\10.6.167.92\KevinDom" as the value for the 'optionalParams' parameters, the "FP_Registration_V2" RPC call succeeds, but 30 seconds later (the heartbeat interval the NetApp simulator uses), the NetApp simulator says there are no servers connected to perform screening. (And yes, my test application does handle and answer the "FP_ServerStatus" method. Remember, everything works as it should when it's all used within some narrow confines. I just want to be able to get it to work outside of those confines too.)
So given the fact that specifying an IP address doesn't work, even when in all the correct confines, I thought, "Well, it must be getting the IP address from the machine name somehow? Let's create both a DNS host name entry and an Active Directory Computer object for my local development machine." After doing that, I can then ping my local development machine from a computer in the test domain by using the host name "KevinProd". That is also the name of the computer object I created in Active Directory. I also modified all attributes of the computer object to match that of the "Server1" computer object for which the test application does work (what I mean is, I didn't copy all attribute values literally, for example, the 'dNSHostName' I entered the value of the DNS record I created).
Doing all that still didn't work. I still don't even see the NetApp simulator in a Wireshark network trace. So what is NetApp doing? Does anyone have any other ideas on how I might get this scenario to work? (I'm not very proficient with Linux/FreeBSD, so if there is a file in some /etc folder that I might be able to edit, let me know and give me lots of detailed steps.)