none
NspiGetSpecialTable RRS feed

  • Question

  • I'm working on an app that needs to pull addresses from exchange.  I've built the IDL outlined in MS-NSPI.  I'm able to call NspiBind to establish a connection but NspiGetSpecialTable returns no rows for the hierarchy table.  I don’t receive any exceptions and exchange is returning RPC_S_OK for NspiGetSpecialTable but the ppRows parameter is always NULL. I'm able to view the hierarchy table in MFCMAPI or Outlook but when called directly the resulting table is always NULL.  I'm testing against Exchange 2003 SP2 and am following the event trace as outlined in MS-NSPI section 4 but cannot get past the call to NspiGetSpecialTable. 

    For kicks, I decided to see what Outlook would do if I returned the same data that I'm getting from Exchange and to make sure I'm sending the right parameters.  Outlook doesn't like it at all and complains that the server is offline.  Are there any special considerations I'm missing?  The IDL is built with: midl /robust /c_ext /oldnames exchange.idl  I've populated the STAT structure according to the spec and compared it with Outlook's STAT structure so I'm pretty certain that part is OK.  I'm using RPC_C_AUTHN_LEVEL_PKT_PRIVACY over RPC_C_AUTHN_WINNT.  Here is the code that is having problems:

     

    STAT Stat;

    PropertyRowSet_r * pRows=NULL;

    FlatUID_r ServerGuid;

    memset(&Stat,0,sizeof(STAT));

    memset(&ServerGuid, 0, sizeof(FlatUID_r));

    Stat.CodePage = 1252;

    Stat.TemplateLocale = Stat.SortLocale = 1033;

    Stat.ContainerID = 0x002627d0; //outlook sends this value, i've tried several values

    Stat.TotalRecs=0x7c910732; //outlook sends this value, i've tried several values

     

    hr = NspiBind(hRPC,0, &Stat, &ServerGuid, &hContext); //binding handle created elsewhere

    hr = NspiGetSpecialTable(hContext,0,&Stat,&dwVersion, &pRows);//returns RPC_S_OK but pRows is always NULL

     

    Can anyone give me an idea why I can't get the hierarchy table?

     

    Thanks in advance,

    David Mott

     

    Wednesday, June 18, 2008 9:48 PM

Answers

  • Tom Devey - MSFT said:

    I spoke with one of the lead developer who is the Subject Matter Expert (SME) for NSPI.  The SME has my sample code along with the IDL files that I tried.  I'm waiting on gettting some feedback on what the issue is and I'm hopefull that will have something in the next few days.


    Developer Consultant


    Good news is the Technical Document Issue (TDI) which was filed against the sourced IDL in the [MS-NSPI] protocol document has been identified.    The issue has been fixed and will be available in a future release of the protocol documentation. 
    Developer Consultant
    Wednesday, August 20, 2008 5:51 PM
    Moderator

All replies

  • David,  Let me see if I can get this working.  Thanks!

    Thursday, June 19, 2008 10:15 PM
    Moderator
  • Thank you Tom,

     

    On the same note, MS-NSPI 3.1.4.1 NspiBind the pServerGuid parameter is a bit sketchy.  Exchange is returning a GUID found in the registry under Cryptography relating to certificate auto enrollment.  Does this GUID represent some certificate or just a random GUID?  The docs only say that the GUID needs to be unique per server.

    Friday, June 20, 2008 10:57 PM
  • David,

    Good question.  Let me ask the document owner for clarification. 


    Developer Consultant
    Wednesday, June 25, 2008 9:15 PM
    Moderator
  • David,

    ok after a few trials and errors I finally got a sample working.    I'm using RPC_C_AUTHN_LEVEL_PKT_PRIVACY over RPC_C_AUTHN_WINNT and works as advertised.

      STAT Stat;
      memset(&Stat,0,sizeof(STAT));

      Stat.CodePage  = 1252;
      Stat.TemplateLocale = 1033;
      Stat.SortLocale  = 1033;

      FlatUID_r ServerGuid;
      memset(&ServerGuid, 0, sizeof(FlatUID_r));

      NSPI_HANDLE hContext = NULL;
      DWORD dwFlags = 0;

      long hr = NspiBind(hRPC, dwFlags, &Stat, &ServerGuid, &hContext);

      DWORD dwVersion = 0;
      PropertyRowSet_r *pRows = NULL;

      dwFlags = AB_ONE_OFF;  // 0x02
      hr = NspiGetSpecialTable(hContext, dwFlags, &Stat, &dwVersion, &pRows);

     for( unsigned long i = 0; i < pRows->cRows; i++)
      {
                    printf("%i", pRows->aRow[i].lpProps->ulPropTag);
      }

    If I use the IDL from the protocol document (which has some syntax problems) I cannot get it to work with my code.  If I use a version used by Outlook I am able to return rows.  A cursory comparison of both IDL sources it appears to be the same but I need to dig into this a bit further.

    I'm filing a bug on the IDL syntax problems that I've found in the protocol document.  I am contacting the PM who is responsible for the NSPI document to see if anything is obvious that I missed.


    Developer Consultant
    Friday, June 27, 2008 2:04 AM
    Moderator
  • Thanks Tom,  I'm looking forward to an updated IDL.
    Monday, June 30, 2008 3:18 PM
  • Hi Tom,  Is an updated IDL going to be included in an upcoming release?  If so, what is the release date?

    Thanks,
    David
    Wednesday, July 9, 2008 6:03 PM
  • Hey David. Unfortunately I don't have a hard release date for you. I'll dig around to see if there's an interim solution.

    R.
    Thursday, July 10, 2008 1:28 AM
  • Any chance you could post a working IDL here? I'm waiting on an answer to this question. Thanks.
    Monday, July 21, 2008 2:36 PM
  • I spoke with one of the lead developer who is the Subject Matter Expert (SME) for NSPI.  The SME has my sample code along with the IDL files that I tried.  I'm waiting on gettting some feedback on what the issue is and I'm hopefull that will have something in the next few days.


    Developer Consultant
    Monday, July 21, 2008 11:17 PM
    Moderator
  • MS-NSPI

    page 47:
    long NspiBind( [in] NSPI_HANDLE hRpc, [in] DWORD dwFlags, [inout] STAT* pStat, [inout, unique] FlatUID_r* pServerGuid, [outref] NSPI_HANDLE* contextHandle );  

    Page 92:

    long NspiBind( [in] handle_t hRpc, [in] DWORD dwFlags, [in] STAT * pStat, [in,out,unique] FlatUID_r * pServerGuid, [out,ref] NSPI_HANDLE * contextHandle );  

    Page 50:

    long NspiUpdateStat( [in] NSPI_HANDLE hRpc, [in] DWORD Reserved, [in] STAT* pStat, [inoutlong* plDelta );  

    Page 93:

    long NspiUpdateStat( [in] NSPI_HANDLE hRpc, [in] DWORD Reserved, [in,out] STAT * pStat, [in,out,unique] long * plDelta );  

    Page 50:

    long NspiUpdateStat( [in] NSPI_HANDLE hRpc, [in] DWORD Reserved, [in] STAT* pStat, [inoutlong* plDelta );  


    Page 93:

    long NspiUpdateStat( [in] NSPI_HANDLE hRpc, [in] DWORD Reserved, [in,out] STAT * pStat, [in,out,unique] long * plDelta );  


    Page 74:

    long NspiResolveNames( [in] NSPI_HANDLE hRpc, [in] DWORD Reserved, [in] STAT* pStat, [in, unique] PropertyTagArray_r* pPropTags, [in] StringArray_r* paStr, [out] PropertyTagArray_r** ppMIds, [out] PropertyRowSet_r** ppRows );   
     

    Page 96:

    long NspiResolveNames( [in] NSPI_HANDLE hRpc, [in] DWORD Reserved, [in] STAT * pStat, [in, unique] PropertyTagArray_r * pPropTags, [in] StringsArray_r * paStr, [out] PropertyTagArray_r ** ppMIds, [out] PropertyRowSet_r ** ppRows );  

    The last one is not so obvious at first glance.  One uses StringArray_r another uses StringsArray_r: 

    typedef struct _StringArray_r {   
        [range(0, 100000)] DWORD cValues;   
        [size_is(cValues)] [stringchar ** lppszA;   
    } StringArray_r;   
     
    typedef struct _StringsArray {   
        [range(0, 100000)] DWORD Count;   
        [size_is(Count)] [stringchar * Strings[];   
    } StringsArray_r;  
    Thursday, July 24, 2008 2:24 PM
  • The code formatting screws up in IE.  I'll repost

    Page 47:

    long NspiBind( [in] NSPI_HANDLE hRpc, [in] DWORD dwFlags, [in, out] STAT* pStat, [in, out, unique] FlatUID_r* pServerGuid, [out, ref] NSPI_HANDLE* contextHandle );
    Page 92:
    long NspiBind( [in] handle_t hRpc, [in] DWORD dwFlags, [in] STAT * pStat, [in,out,unique] FlatUID_r * pServerGuid, [out,ref] NSPI_HANDLE * contextHandle );


    page 50:
    long NspiUpdateStat( [in] NSPI_HANDLE hRpc, [in] DWORD Reserved, [in] STAT* pStat, [in, out] long* plDelta );
    page 93:
    long NspiUpdateStat( [in] NSPI_HANDLE hRpc, [in] DWORD Reserved, [in,out] STAT * pStat, [in,out,unique] long * plDelta );

    page 74:

    long NspiResolveNames( [in] NSPI_HANDLE hRpc, [in] DWORD Reserved, [in] STAT* pStat, [in, unique] PropertyTagArray_r* pPropTags, [in] StringArray_r* paStr, [out] PropertyTagArray_r** ppMIds, [out] PropertyRowSet_r** ppRows );

    page 96:
    long NspiResolveNames( [in] NSPI_HANDLE hRpc, [in] DWORD Reserved, [in] STAT * pStat, [in, unique] PropertyTagArray_r * pPropTags, [in] StringsArray_r * paStr, [out] PropertyTagArray_r ** ppMIds, [out] PropertyRowSet_r ** ppRows );

    Thursday, July 24, 2008 2:31 PM
  • David,

    I have filed a bug against the documentation on the method signiture differences you mentioned above.

    Thank you for providing feedback.

    Developer Consultant
    Thursday, July 24, 2008 5:40 PM
    Moderator
  • David Mott said:

    Thank you Tom,

     

    On the same note, MS-NSPI 3.1.4.1 NspiBind the pServerGuid parameter is a bit sketchy.  Exchange is returning a GUID found in the registry under Cryptography relating to certificate auto enrollment.  Does this GUID represent some certificate or just a random GUID?  The docs only say that the GUID needs to be unique per server.



    The documentation say it needs to be unique per server and may be different in each session to the server because that is the only restriction.  It represents the server during the lifetime of a server.  A server can change the value without constraint over time, but can't change it during an NSPI connection.

    It's value on input is not constrained, you just have to pass in enough space.

    As for the GUID in the registry that has nothing whatsoever to do with the GUID that's returned.  What is returned is the invocation ID.   This is a GUID associated with a specific active directory server that resets if you restore the server from backup or auth-restore an object on the server.  Either of these actions bring down the server, thus breaking any NSPI connections.  That's why it states in the documentation that it can change over time but it must be constant during any RPC connection.


    Developer Consultant
    Thursday, August 7, 2008 5:19 PM
    Moderator
  • Tom Devey - MSFT said:

    I spoke with one of the lead developer who is the Subject Matter Expert (SME) for NSPI.  The SME has my sample code along with the IDL files that I tried.  I'm waiting on gettting some feedback on what the issue is and I'm hopefull that will have something in the next few days.


    Developer Consultant


    Good news is the Technical Document Issue (TDI) which was filed against the sourced IDL in the [MS-NSPI] protocol document has been identified.    The issue has been fixed and will be available in a future release of the protocol documentation. 
    Developer Consultant
    Wednesday, August 20, 2008 5:51 PM
    Moderator