Forum Discussion

EVSpinner's avatar
EVSpinner
Level 5
11 years ago
Solved

Any stone unturned - removing inherited permissions?

Hi everyone,

I have a scenario where an Archive (EV10) has inherited permisions assigned to it but the user has left the organisation - Exchange mailbox and AD object already deleted. Zero day archive completed BUT permissions not zapped before they were deleted

I've now been asked to remove the permissions

No problem, you say - initiate zap archive permissions

Except that when I do, I get an error - Event ID: 3473 One or more errors occurred during the creation of a profile to connect to an Exchange Server

Ok, still no problem. Resolve issue using the following (troubleshooting points to these Technotes as most significant)

http://www.symantec.com/docs/HOWTO57522

http://www.symantec.com/docs/TECH139751

 

Here is the problem though. The person  I need to follow these Technotes, or allow me to use these Technotes to solve the Event ID: 3473 doesn't want to do this (and has not been specified about why)

The person really, really wants to remove these permissions in SQL, which I neither know how to do, nor think is a very good idea (why not solve the problem at root, as above?)

Apart from a real cowboy workaround of applying an explicit deny in the manual permissions, can anyone think of anything else I can try to remove these permissions that doesn't incldue zap?

Just out of curiosity, why does EV need to make an Exchange connection at all, if all I want to do is remove archive permissions?

  • All a permissions zap does is just set the AuotSecurityDesc and ManualSecurityDesc columns in the Root table entry to NULL, that's it, the need for an exchange connection is aimless but that's just how EVPM works
  • To be honest I would suggest that it is something that can be easily overcome.

    I very much doubt you are experiencing a lack of NSPI connections as you are only trying to make a VERY limited amount of connections using EVPM, something the environment should handle in its sleep, the NSPI technote is used/seen during Archiving etc where LOADS of connections are made in a very short period of time.

     

    From what you have provided I would say you are simply having a problem making a MAPI connection to the Exchange Server/GC.

    When you use EVPM you specify a mailbox and Exchange Server, if you try to create a new Outlook profile using those details does the name resolution work as expected or does it fail to resolve the name?

    Enter the mailbox and Exchange server EXACTLY the same as the way they are specified in your EVPM command.

     

    Also, just a side question, do you use a NLB?

    If you do then they are well known for causing issues with EV and will need to be worked around.

     

    Of course you could grab a Dtrace during the EVPM operation to find out the exact error and at which point.

  • All a permissions zap does is just set the AuotSecurityDesc and ManualSecurityDesc columns in the Root table entry to NULL, that's it, the need for an exchange connection is aimless but that's just how EVPM works
  • I would retry the command, using the commandline to enter the values step by step. I have had this occasionally, and it always was a type from my side. (either using the wrong Exchange-server, or systemmailbox etc).

    I would definitely NOT do this from SQL, although JW3 indicated what needs to be changed.

    I would make very clear that changing it in SQL might have sideeffects (although that's not true, but scare them off :-) ), and is definitely not supported by Symantec.

  • Brilliant, sort of what I expected, but thank you for your input

    Ben - Thanks for clarifying the NSPI.  The 3473 came from DTrace. Totally with you on the fix at source/closest GC route, but there appears little appetite for this (shrugs shoulders). no problem....NEXT

    also from the same DTrace: 

    1263        15:39:12.757         [8856]        (EVPM)        <15220>        EV:H        {CMailboxHelper::BuildConfigureMsgServiceErrorText:#688} Failed to contact server due to a network error.

    1264        15:39:13.069         [8856]        (EVPM)        <15220>        EV~E        Event ID: 3473 One or more errors occurred during the creation of a profile to connect to an Exchange Server. |Targeted Exchange Server: |ConfigureMsgService failed with the following errors: |A network error MAPI_E_NETWORK_ERROR has been reported for the following connection points:| Cleaning up profile following preceding failure. Profile deletion: [0x0]

     

    JW3, thanks for the SQL hint. Worth banking that for future reference

     

    Will follow up regards NLB

     

    Gertjan, I never thought about the Outlook profile - good idea, and yes, my first thought was I'd entered the zap details incorrectly. I get 0x80040115 creating privileged MAPI session against Exchange server (I have tried using FQDN)

     

    If I get a solution/conclusion to this, I'll update the thread for someone elses future reference

     

    Thanks again for your input chaps. Much appreciated

  • Removing Perms from SQL is not as easy as it sounds due to the constraints and PK/FK between tables.

    As much as JW3 is 100% correct, as usual, in that all it (evpm) does is effectively strip the values within the 'cells' in SQL, the easiest and, as Gertjan mentions, ONLY supported way is via EVPM so get that working and all will be well.

     

  • Cheers Ben, I totally understand and don't intend going 'off piste'