Big G! :)
Sebastian Canevari
Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM
7100 N Hwy 161, Irving, TX - 75039
"Las Colinas - LC2"
Tel: +1 469 775 7849
e-mail: seba...@microsoft.com
-Original Message-
From: cifs-protocol-boun...@cifs.org [mailto:cifs-protocol-boun...@cifs.
Tridge,
After a further review, we identified two more bits that could be observed
on wire.
DRS_INIT_SYNC_NOW 0x0080
DRS_PREEMPTED 0x0100
A description of these two bits and the DRSUAPI_DRS_NEVER_SYNCED bit you
mentioned is shown as below.
NSY (DR
Thanks for the advisory - I will follow up with you on the attid - I will be
expanding my code study on this.
Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
TEL: +1(980) 776-8200
CELL: +1(704) 661-5438
FAX: +1(704) 66
Hello again, Kamen. Could you forward the LDIF file to me? I want to make sure
I haven't missed anything (thanks).
Also, I have again reviewed the MakeAttid() and OidFromAttid() pseudo code in
[MS-DRSR] 5.16.4 (ATTRTYP-to-OID Conversion) - they do appear to be accurate
representations of our im
You are very welcome. Could you advise me concerning how much this is affecting
your implementation development, so that I can set the TDI priority
appropriately?
I have cross-compared the Windows 2003 and Windows 2008 R2 implementations of
the MakeAttid() and OidFromAttid() functions; there a
Hi Bill,
Thanks for your support.
I am looking forward to hearing from you soon.
Regards,
Kamen Mazdrashki
kamen.mazdras...@postpath.com
http://repo.or.cz/w/Samba/kamenim.git
-
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/
> -Original Messag