Earlier this week I ran into the following error “The requested object : securitygroup-xxx could not be found. Object identifiers are case sensitive.”. You can come across this error when you try to export your NSX firewall config. Or at the service composer at the top in a warning bar. The error basically means that a security policy still uses a security group that no longer exists.

To resolve this error you need to find the security policy that contains the deleted security group and adjust this policy accordingly. A security policy that uses a deleted security group will look as shown in the screenshot below.

Now in a small environment you could open up the few security policies that are present. But when you start getting a lot security groups and policies, this would not be a very efficient way. Luckily there is another way to find the security policy that is using a deleted security group.

NSX API

Using the NSX API you can retreive all your security polices including all the firewall rules and security groups (including the object id “securitygroup-xxx”) within the policies. The API call used to do this would be https://nsx_manager/api/2.0/services/policy/securitypolicy/all

Since the security group doesn’t exist anymore you can’t just perform a search for the object id mentioned in the error. As shown in the XML below there is no security group information available. This test policy only contained one security group and that one was deleted.

<?xml version="1.0" encoding="UTF-8"?>
<securityPolicies>
    <securityPolicy>
        <objectId>policy-14</objectId>
        <objectTypeName>Policy</objectTypeName>
        <vsmUuid>420DBB6E-3037-757B-14A9-507ED1E2EFF3</vsmUuid>
        <nodeId>560c4014-49ee-4cc0-8635-37c7159959a9</nodeId>
        <revision>5</revision>
        <type>
            <typeName>Policy</typeName>
        </type>
        <name>testing</name>
        <description></description>
        <scope>
            <id>globalroot-0</id>
            <objectTypeName>GlobalRoot</objectTypeName>
            <name>Global</name>
        </scope>
        <clientHandle></clientHandle>
        <extendedAttributes/>
        <isUniversal>false</isUniversal>
        <universalRevision>0</universalRevision>
        <inheritanceAllowed>false</inheritanceAllowed>
        <precedence>7300</precedence>
        <actionsByCategory>
            <category>firewall</category>
            <action class="firewallSecurityAction">
                <objectId>firewallpolicyaction-12</objectId>
                <objectTypeName>FirewallPolicyAction</objectTypeName>
                <vsmUuid>420DBB6E-3037-757B-14A9-507ED1E2EFF3</vsmUuid>
                <nodeId>560c4014-49ee-4cc0-8635-37c7159959a9</nodeId>
                <revision>4</revision>
                <type>
                    <typeName>FirewallPolicyAction</typeName>
                </type>
                <name>testrule</name>
                <scope>
                    <id>globalroot-0</id>
                    <objectTypeName>GlobalRoot</objectTypeName>
                    <name>Global</name>
                </scope>
                <clientHandle></clientHandle>
                <extendedAttributes/>
                <isUniversal>false</isUniversal>
                <universalRevision>0</universalRevision>
                <category>firewall</category>
                <executionOrder>1</executionOrder>
                <isEnabled>true</isEnabled>
                <isActionEnforced>false</isActionEnforced>
                <invalidSecondaryContainers>true</invalidSecondaryContainers>
                <invalidApplications>false</invalidApplications>
                <logged>false</logged>
                <action>allow</action>
                <direction>outbound</direction>
                <outsideSecondaryContainer>false</outsideSecondaryContainer>
            </action>
        </actionsByCategory>
        <statusesByCategory>
            <category>firewall</category>
            <status>in_sync</status>
        </statusesByCategory>
    </securityPolicy>
</securityPolicies>

Instead of the object id you will need to look at a value called invalidSecondaryContainers. In a normal situation this value is set to “false”, but in the example you can see that it is set to “true”.

<invalidSecondaryContainers>true</invalidSecondaryContainers>

PowerNSX

With the reply of the NSX API you could create your own code and process it anyway you like. But if you want a nice and quick way to find the faulty security policy. Then PowerNSX is the way to go. If you are not familiar with PowerNSX then you can read about it in the article Martijn wrote.

Using PowerNSXl you could retreive the faulthy policy in one line of code:

get-nsxsecuritypolicy | where-object { $_.actionsByCategory.action.invalidSecondaryContainers -like "True" }

The first part will get all the security policies that are present in your environment. And the second part will select all the security policies where the invalidSecondaryContainers is set to “true”.

Now that you know which security policy contains the missing security group you can go back to the vSphere web client and fix the policy.