You will want to access the McAfee support portal and login with your support account:
And download from the McAfee Network Security Platform category (you will need to provide a grant number)
Download the McAfee NSP Manager Software applicable to your version.
Thank you so much for the reply....
while installing the software in windows server, I connected this windows server to IPS management port.
What I have to do in the windows server control panel to set the IP of the server. I am sorry, I am very much new to this device, Can you please explain me what all I have to do to make the device up n working.
Since you are able now to login to the NSM I see that you have resolved your IP issue.
The next step as you have started is to add the sensor(s) to the NSM.
There are prequisites that are needed for that process to complete properly:
Open the ports between the NSM and the sensor(s).
UDP - NSM Source port 4167 to Sensor listening on UDP 8500
UDP - Sensor Source port 8500 to NSM listening on 4167
TCP - Sensor listening on TCP port 8501 through 8504
TCP - Sensor listening on port 22 for SSH connectivity
Usually if the sensor is on the same segment as the NSM this is not an issue but there is any firewall between the sensor and NSM you will need to have the FW Admin add those ACLs.
You would also want to ensure that any Local Firewall on the NSM Server allows all that as well (whether speaking Windows FW or an application FW installed on the NSm server).
Once those prerequisites are in place you then start the sensor setup/install:
1. Add the sensor by name into the NSM's Device list - creating the secretkey as you do.
This will prep the manager for having the sensor 'call-in' later in the steps.
The sensor will show up in the NSM Home page as "unknown"
It will not be listed in the Configure Page/Resource Tree yet.
2. On the sensor type 'setup' and configure the name to match, the IP, Mask, and Gateway info. Also define the IP address of the NSM server. Reboot the sensor to embed that information on the sensor.
3. On the sensor CLI type "show mgmtport' to show what the speed/duplex has negotiated to. If the link has negotiated to a half-duplex conenction that can impact on the sensor being able to recieve the data package during the next steps of connecting the sensor to the NSM.
Example: The management port on the sensor defaults to AUTO negotiate. If the switch that it is conencted to is hard-coded to Full-duplex then the link will usually negotiate to 10 or 100 Half-duplex. You can change the switch to be AUTO to match that of the sensor or you can hard-code the sensor management port to also be Full duplex.
Example: set mgmtport speed 100 duplex full
Now that you have all the ACLs in place and a solid management port speed/duplex link established you can perform the next step in the process which is to establish the connection between the NSM and the Sensor.
4. On the sensor CLI type:
set sensor sharedsecretkey
This will first set up a secure trust between the sensor and the NSM. (You'll see that as "Trust = Yes" when running the "status" command from the sensor cli while the sharedsecret key process is going through its paces.
You then should see (keep entering 'Status" command every 10-15 seconds) the Alert, Packetlog, and Command channel change from DOWN to UP.
Once that completes the sensor will now show up in the Resource Tree under the Configure page of the NSM.
The process so far has just set up the communication channels. The NSM will now query the sensor for a bunch of info .. name, ip, model, version, how long running, configuration state data -- basically getting an inventory of information ABOUT the sensor.
Using that information it compiles a configuration package for the sensor that includes the default policy, global settings, etc and pushes that out to the sensor.
You can 'track' that process in several manners:
From NSM go to the Configure Page -- Select the Domain (My Company level) and from the menu select LOGS then submenu - Long Running Processes. You should see the Update package (says something like Signature set update in Progress) being pushed to the sensor.
If this is successful THEN the sensor will populate into the Resource Tree of the NSM and the "Unknown" state will clear and it will show that the sensor is ACTIVE.
That data package is transferred over the TCP port 8504 that you made sure was opened.
The other way to track the progress of the configuration push to the sensor is from the sensor CLI.
After you see that the TRUST = Yes and all the channels show UP.. type:
It will show you the progress of the data transfer.
Note .. that the NSM compiles the package after the first part of the sharedsecret process and then pushes that to the sensor. Point is that it can take up to 4 or 5 minutes before the actual data transfer starts so be patient when looking at the download status output .. I usually just trust the NSM's long-running process to tell me when the package has been transferred successfully. If there is a problem and it fails I will then look at the error message for the sensor in the NSM Fault Status page and run the download status on the CLI to see if it tells me why it failed.
If it DOES fail then the sensor will not be manageable from the NSM (because that 'package' included info for the sensor about how the two (NSM and Sensor) would communicate.).
You can see that the "Unknown" state that you are asking about exists as the expeected state until the sensor is completely joined to the NSM... so the answer to your question is that it could be several causes as outlined in the processes above. Any failure along the way can result in that status ...
So - review the processes as described and see what did not happen.
For instance .. that configuration push to the sensor can fail if port 8504 sees a lot of CRC errors .. which is a condition that a Half-Duplex link of the management port will see if you have that AUTO versus Fixed mismatch between the sensor and the switch.
Hope this helps!