Doing an upgrade to 11.1.1.36 and updated my workstation to use the 11.1.1.36 client. When I go to get reset my password I get this message:
The server did not respond (1232). Make sure th is server is running Netwrix Password Policy Enforcer V11.2 or later, and RPC port on endpoint \pipe\PPE is not blocked by a firewall.
If I roll it back to 11.0.2.14 (what we have deployed everywhere else), it works fine.
Looks like a bug in the PPE client??
I have not seen this exact error before, but it is possible that with 11.0 you are using UDP and the 11.1 client is using RPC as its communication method based on the communication error presented. You can try the following troubleshooting steps below for RPC.
\# Check the status of services
sc query RpcSs
sc query DcomLaunch
net stop RpcSs
net start RpcSs
net stop DcomLaunch
net start DcomLaunch
Make sure RPC ports (135, dynamic ports) are open
Check exceptions for your application
\# Check connection
ping <server>
\# Check RPC connection
rpcdump /s <server>
Check:
all of the 11.1 doc say it should be using UDP still… (see below) Why would it change?
Also, why would it reference 11.2 when everything is 11.1.36?? Did someone push a feature foreward to the 11.1 code that is supposed to be part of 11.2?
The default for PPE 11.1 will be RPC, where the default used to be UDP. Right now 11.1 runs UDP and RPC on the server level, allowing the client to connect using either or. Your client is reaching out via RPC (based on the communication error presented referencing RPC) and is not getting a response due to a communication error. RPC is a dynamic range of ports rather than a set port like UDP 1333.
I am unsure on why the 11.1.1.36 client would reference a PPE version that is not released, perhaps the build of the client currently in use was originally being worked on for 11.2 and the message was not altered before being worked on for a build fix in 11.1.1. I have inquired internally, but it is most likely just a visual that was not caught before releasing of 11.1.1.36.
The plan will be to completely get rid of supporting UDP with the product somewhere around 11.2 if not 11.2 completely. RPC will be the communication method going forward and UDP will no longer be usable. This is most likely the case on why the UDP documentation is still in place, but not a reason on why RPC documentation is missing.
If you wish to keep using UDP for now and figure out the RPC communication problems later, you can use a registry edit to force the PPE Client to use UDP again. However, please keep in mind that you will need to put these registry values on every machine you want the PPE Client to work on.
To do this, you can navigate to (or create it if it is missing) the registry location of: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\ANIXIS\Password Policy Client
Create two values:
DWORD named “TypeCommunication” with a value of “0”. This tells the PPE Client that its communication method should be UDP, value of “1” will be communication method of RPC.
DWORD named “Port” with a value of your desired UDP Port (by default this is 1333).
Examples of these two values:
So… got back to digging on this, because earlier I wasn’t seeing the blocks in firewall logs, I took a different tack…
RPC starts with 135 and the mapper says use one of the high range ports “typically” 49152-65535.
Using procmon, loginUI.exe is reaching out on TCP/1344… its consistent between domain controllers… So I feel like this isn’t a purely RPC/RPC Mapper…
AND THEN I FOUND THIS:
SO YES, RPC, but on a standard TCP port that’s configured in the gui…
The docs need to be updated….
We also saw this same error and ended up rolling back a version at first, but then publishing the new version and pushing out the registry edit to all machines to continue using UDP as we couldn’t find the cause.
The release notes made no mention of the traffic protocol changing and as we only have the required ports open over our VPN and firewalls, nor does the documentation mention any specific ports, so presumably PPE is using some undocumented port that we don’t have open on our network.
We’re looking into the protocol issue as a few customers have run into it. The documentation issues are also noted. Switching back to the UDP protocol is fine for now if you have problems with RPC. The UDP protocol will be removed eventually, so keep an eye on the release notes.
