Tech Tweets

    follow me on Twitter
    AddThis Social Bookmark Button
    Blog powered by Typepad

    March 2021

    Sun Mon Tue Wed Thu Fri Sat
      1 2 3 4 5 6
    7 8 9 10 11 12 13
    14 15 16 17 18 19 20
    21 22 23 24 25 26 27
    28 29 30 31      

    Become a Fan

    « The MobileMe Saga Begins | Main | Me Can't Handle It »

    July 15, 2008


    Cameron Lackpour

    Have you tried the MaxL command
    alter system resync sss?

    There are also versions of this at the app and user level, e.g.,
    alter application sync user user-name/group group-name/all_users_groups


    alter user sync security with all application

    I have to say I haven't personally used these functions but they're documented in the Fine Manuals you referred to.

    Or do they not work?


    Cameron Lackpour


    It sounds simple until you try it. We've had issues with MSAD availability today which has complicated matters once more. Here's an example of what slows things down:

    I've got a group with 3000 users in it from two different MSADs. I'm trying to replicate that on a new server. If there is one, just one, user that cannot be found when you update the group, then the entire update of the group fails. You have no idea how many of the users are no good until you run it 3000 times. There are no 'rejects'.

    It doesn't matter what's actually IN the MSADs, what matters is what Shared Services SEES. There is no way to tell, in advance, what Shared Services can or cannot validate with regard to populating user groups.

    My shortcut has been to run the import multiple times and generate a blacklist (manually) of all rejected users, recreate my import list minus the blacklisted users and try again. I did this for two hours until I realized that I could potentially be running this script forever.

    I reran an export of the users to see if perhaps I could do an outer join and find the excluded users, and it turns out that Shared Services only recognized 96 Native Directory users. So all this time MSAD might have been down, but running the batch tools CSSImport and CSSValidate give you no idea about such things.


    Sanjay Roy says a bunch at Network54
    This discourse is only valid when we have externalized ESSBASE security to Shared Services.
    These are the following steps (works consistently in HYS, and
    Case 1 :
    If we are using the Native Directory for storing the user/group credentials
    1a) Create the user in Native DIrectory (Using Web Console)
    1b) Run the MAXL "create user type external ;" (Step 1a is needed for this to work)
    what this will do is
    - create the user is ESSBASE (create entry in the $ARBORPATH/bin/essbase.sec file) and
    - give the user "Server Access" provisioning in Shared Services.
    1c) grant the user application/filter access (use grant command). This will also update the application provisioning in Shared Services.
    1d) This is required if and only if the user security/application needs to be refreshed.
    alter user sync security with all application ;
    alter application sync user ;
    The 4 steps also creates the relevant provisioning in Shared Services as well and syncs them with the essbase.sec file.

    So, MAXL sets up security in ESSBASE as well as set the security in the Shared Services repository.
    You can also use alter system resync sss;
    - to refresh all the security from Shared Services repository to ESSBASE.

    When we delete the registered application in Shared Services all the security related to the ESSBASE application is lost.
    Also if the $ARBORPATH/bin/essbase.sec file is dropped or corrupted, SHared Services cannot sync the entries in the repository with the $ARBORPATH/bin/essbase.sec file and hence cannot refresh. In that case the ESSBASE agent will not start as CSS authentication will fail.

    For groups in native directory, i have seen in, that running the MAXL
    create group type external;
    creates the group (yes, it creates the group) in the Native-directory (if the same group does not exist in any other user-directory registered with Shared Services).And it also does the same provisioning in Shared Services as discussed for the user. The MAXLs will be the same except for the fact that you need to substitute the keyword user with group.

    Case 2 :
    If we are using the another external LDAP (SunOne, MSAD) for storing the user/group credentials.
    2a. The user/group needs to be created in the external LDAP.
    2b) Run the MAXL "create user type external ;" (Step 2a is needed for this to work)
    If the use does not exist in the Native-LDAP or any of the external LDAPs registered with Shared Services, it will throw error. In case of groups as I said, if it does not find the group in any of the external LDAPs registered with Shared Services, it will create the group in Native Directory.
    Follow 1(c) and 1(d).

    And as said, MAXL sets up security in ESSBASE as well as set the security in the Shared Services repository.
    Hope this helps

    buy viagra

    I have a print titled "Jungle Ruler" by artist John Pitre. It
    appears to have been a water color originally, but I am not certain of
    that. It is blue. It is numbered 106 out of 250 and is 23" X 35" in


    I get a lot of great information here and this is what I am searching for. Thank you for your sharing. I have bookmark this page for my future reference. Search aws openings in hyderabad.

    Verify your Comment

    Previewing your Comment

    This is only a preview. Your comment has not yet been posted.

    Your comment could not be posted. Error type:
    Your comment has been posted. Post another comment

    The letters and numbers you entered did not match the image. Please try again.

    As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

    Having trouble reading this image? View an alternate.


    Post a comment

    Your Information

    (Name is required. Email address will not be displayed with the comment.)