570 likes | 847 Views
TOI Cisco Unity 8.0(3). TOI Cisco Unity 8.0(3). TOI for Unity Reader. Erich Von Normann Cisco Unity Development evonnorm@cisco.com. Intro to Unity Connection Networking.
E N D
TOICisco Unity 8.0(3) TOI for Unity Reader Erich Von Normann Cisco Unity Development evonnorm@cisco.com
Intro to Unity Connection Networking • Cisco Unity 8.x and Cisco Unity Connection 8.x can be networked for exchange of directory information, voice messaging, call processing, and migration. • This module will include information about the directory exchange and details on the Unity Reader component. • There are many other TOIs for other parts of the feature.
Module Objectives • After completing this module you will be able to: • Describe the design of the Unity Reader • Understand the diagnostic traces for the Unity Reader • Troubleshoot some problems related to the Unity Reader This TOI assumes that you already have some background information on the design of the Connection Networking Feature. Also, the material in this TOI is closely related to the material in the TOIs on the Unity Feeder, and Connection Reader and Feeder.
Agenda • Intro to Directory Exchange • Purpose of the Unity Reader • Details of the Reader Design • Reader Troubleshooting
Intro to Directory Exchange • Unity and Unity Connection use a Reader-Feeder paradigm for directory exchange. • A Feeder is a website that presents directory information and voicename recordings taken from the local database • A Reader is an application that periodically accesses the remote Feeder to pull directory information and voicename recordings, and write them to the local database • The directory information is presented in an XML format • Authentication is required in order to access confidential directory information (though authentication can be unlocked for troubleshooting) • The Initial Synk (just after the 2 systems have been joined) can take awhile depending upon the directory size, but later updates will only synk down changes since the last cycle.
Overview of Feeder Architecture • Unity and Connection each implemented a Feeder • The Feeder is a website that publishes several URLs: • <server>/feeder/info • Provides the XML templates for the published objects • Lists all locations in the local digital network • Provides count of each object type • Lists the replication sets (used with backup / restore scenarios) • <server>/feeder/objects • Provides the XML for each exported object, including ObjectID, Alias, Names, Extensions, SMTP Addresses, and others • By default, it requires authentication to view (TAC can disable authentication requirement for troubleshooting) • Can take various parameters (start/end USN, object type, rep set, etc.) • <server>/feeder/object/<objectid>/voicename • Provides the wave data for an object’s recorded name (if any) • Admin can specify the codec in which the wave data is presented
Overview of Reader Architecture • Unity and Connection each implemented a Reader • The Reader is a Unity service that pulls down Connection’s feeds and writes the objects to SQL and AD • Periodically (default is every 15 minutes), it will request all new objects, meaning all objects whose USN is above the previous high-water mark. • Then, it parses the object feed, and writes each new, changed, or deleted object into its local SQL database. • Next, it writes the object to Active Directory, which will in turn replicate each object to other Unity servers in the digital network (who synk the objects into their local SQL databases). • If an object’s voicename has changed, it will request the voicename from the Cxn Feeder, and write that it to SQL and AD as well. • The Reader supports several Admin actions from the Unity SA, such as: • Resynk now (rather than waiting until the next interval) • Resynk all (starting at USN 0 rather than the high-water mark) • Unjoining (to delete all imported objects and tear down the joined network)
Limitations of Unity Connection Networking • Directory Exchange is only supported on the Primary Unity Server in a Unity Failover Pair. • No Directory Exchange will happen when the Secondary Unity Server is active (ie, the system is “failed over”) • When the Primary Unity Server becomes active (ie, the system has “failed back”), Directory Exchange will resume. • Server Hardware in the Platform Overlay One category (ie, 7825s running MSDE) do not scale well to large combined Unity and Unity Connection directories. • We highly recommend that larger sites use Platform Overlay Two or Three (ie, 7835s or 7854s running full MS SQL Server) for their Unity Site Gateway and other servers in their Unity digital network.
Info Feed URL requests The Info Feed does not require authentication and always take the following URL format: http[s]://<server>/feeder/info The Info Feed is used both during the join process from the Unity SA, and at run-time by the Reader each time it does a synk cycle. A sample Info Feed response will be shown over the next few slides.
Info Feed Response (part 1) Info Feed Header Site Gateway (Bridgehead) <info maxObjectsPerRequest="500" product="Unity Connection/8.0.0.270"> <locations> <location bridgehead="true" hostaddress="10.93.236.29" id="86e3d148-551a-4f8c-bd33-d5d3275fd05b" name="sea-vm-ks-10" smtpdomain="sea-vm-ks-10.cisco.com" systemversion="8.0.0.270" unitypartitionobjectid="251e317e-5d7d-468c-b0b4-5d8060a96cd4"/> <location bridgehead="false" hostaddress="10.93.236.30" id=“0cfa514e-a297-4b15-9645-2e5377175c7a" name="sea-vm-ks-11" smtpdomain="sea-vm-ks-11.cisco.com" systemversion="8.0.0.270" unitypartitionobjectid="a81e18ad-1e76-4a78-af0a-e244cbf32f42"/> </locations> <replicationSets> <replicationSet id="e82c3c01-cbec-4c98-87c9-0c25521a0b30"/> </replicationSets> <objectCounts>...</objectCounts> Location ObjectID Unity Partition ObjectID Cxn Member Server Unity uses Site Gateway’s SMTP Domain instead Replication Sets(multiple if backup/restore) Unity ignores ObjectCounts(Cxn has DB Limits)
Info Feed Response (part 2) Object Definitions Unity doesn’t use these 3 <attributes> <searchspace>...</searchspace> <partition>...</partition> <list>...</list> <contact>...</contact> <user> <a name="alias"/> <a name="xferstring"/> <a name="extension" type="multi"> <a name="extension"/> <a name="locationobjectid"/> <a name="index"/> <a name="partitionobjectid"/> <a name="partitionname"/> </a> ... </user> </attributes> </info> Lists condensed for brevity(similar to users) User Object Definition Single-value Attributes A multi-value Attribute Others omitted for brevity
Objects Feed URL requests The object feed URL can take several optional parameters after the ? • start=<usn> - USN at which to begin (default is 0 if not specified) • end=<usn> - USN at which to stop (default is last USN if not specified) • objectType=<type> - can be user or list (default is all if not specified) • rs=<id> - Replication Set to use (default is current if not specified) For example, to ask for just users starting at USN 100, use this URL: http[s]://<server>/feeder/objects?start=100&objectType=user To ask for both users and lists from USN 200 to 1000, use this URL: http[s]://<server>/feeder/objects?start=200&end=1000&objectType=user&objectType=list
Objects Feed Response (part 1) USN of last object The objects feed will always have a header block like the following: <objects lastUsn="69" maxObjectsPerRequest="500" numObjects="8" product="Unity Connection/8.0.0.270"> This header will be followed by a number of objects, each described in an XML format. A sample object will be shown over the next few slides. Limit per request Objects in this response
Objects Feed Response (part 2) Object Header(ObjectID, Type, and USN) Here’s the beginning of an object from the objects feed: <object id="b9c007ae-defa-4dd2-9ae4-4e23a8328c7d" type="user" usn="69"> <a name="xferstring" null="true"/> <a name="dignetobjectidtimestamp" value="0"/> <a name="alias" value="CxnDude"/> <a name="listindirectory" value="1"/> <a name="lastname" value="Dude"/> <a name="firstname" value="Connection"/> <a name="locationobjectid" value="86e3d148-551a-4f8c-bd33-d5d3275fd05b"/> <a name="dignetobjectid" value="b9c007ae-defa-4dd2-9ae4-4e23a8328c7d"/> <a name="voicename" value="ed943f03-dc4e-4018-8ca7-492ad58b24d2.wav"> <a name="gatewayaddress" value="b9c007ae-defa-4dd2-9ae4-4e23a8328c7d@sea-vm-ks-10.cisco.com"/> <a name="displayname" value="Connection Dude"/> Location ObjectID Recorded VoiceName Unity uses LocalPart ofGatewayAddress and Site Gateway’s SMTP Domain
Objects Feed Response (part 3) Extension Value Primary Extension (Index 0) <a name="extension"> <v id="aec68edd-1533-4b12-a2de-1f1295f5169c"> <a name="extension" value="12345"/> <a name="locationobjectid" value="86e3d148-551a-4f8c-bd33-d5d3275fd05b"/> <a name="index" value="0"/> <a name="partitionobjectid" value="251e317e-5d7d-468c-b0b4-5d8060a96cd4"/> <a name="partitionname" value="sea-vm-ks-10 Partition"/> </v> <v id="0dd9bdfa-0e1b-4825-b6fc-7e40f758edf6"> <a name="extension" value="8675309"/> <a name="locationobjectid" value="86e3d148-551a-4f8c-bd33-d5d3275fd05b"/> <a name="index" value="3"/> <a name="partitionobjectid" value="e12ee23c-49ae-4cd4-b6d7-9ad60197b545"/> <a name="partitionname" value=“Non-Unity Partition"/> </v> </a> Alternate Extension Different Partitions
Objects Feed Response (part 4) Can have multiple SMTPAddresses on Cxn <a name="smtpaddress"> <v id="3a80cf19-26dc-4b0c-a099-cde9dd4369a9"> <a name="smtpaddress" value="cxndude@sea-vm-ks-10.cisco.com"/> <a name="primary" value="true"/> </v> </a> <a name="alternatename"> <v id="c95fe4ba-a09d-4356-afb8-285bfc79d9fc"> <a name="lastname" value="Rocks"/> <a name="firstname" value="Testing"/> </v> </a> </object> Unity uses LocalPart of Primary SMTPAddr for Alias Alternate names
VoiceName Feed URL requests The Info Feed does not require authentication and takes the following URL format: http[s]://<server>/feeder/object/<objectid>/voicename If the Reader notices an object’s voicename has changed (either because it’s a new object, it’s gone from NULL to non-NULL, or otherwise changed), Unity will make a request to the VoiceName Feed. For example, if object b9c007ae-defa-4dd2-9ae4-4e23a8328c7d now has voicename ed943f03-dc4e-4018-8ca7-492ad58b24d2.wav, Unity will use this URL to retrieve it: http[s]://<server>/feeder/object/b9c007ae-defa-4dd2-9ae4-4e23a8328c7d/voicename The VoiceName will be returned as wave data in the codec specified on the Connection server’s SA page.
Client of Cxn Feeder: Periodically requests Feeds,Parses XML for Objects, Hands Objects to DirWriter Libraries to support Authentication, Signing, and Verifying Feeds. Unity Reader Architecture Control Module:Starts/Stops Service, Responds to Config Changes, Resynk Requests, etc. Writes to SQL: Receives Objects from Client, Writes them to SQL. Success Pass to DirSynker Failure Re-queue at Client Writes to Active Directory: Receives Objects from DirWriter, Writes them to AD. Success DONE! Failure Re-queue at Client VoiceNames:If DirWriter finds a change, it makes a request to Client. Client requests VoiceName Feed, then hands to DirWriter/Synker.
Unity Reader Threading There are 5 threads active within the Unity Reader: • ReaderAdminThread in CDirReader • Responds to Config Changes, Resynk Requests, & Writes Perf Counts/Times • ObjectReadThread in CFeederClient • Periodically requests Info & Objects Feeds, and parses the XML • Pushes parsed Objects onto DirWriter queue • DirWriterThread in CDirWriter • Pops Objects off its queue, and writes them to SQL • Pushes Objects onto either DirSynker queue (Success) or ClientRetry queue (Failure) • DirSynkerThread in CDirSynker • Pops Objects off its queue, and writes them to AD • Pushes Objects onto ClientRetry queue (Failure) • Also pops voicenames off a queue and writes them to AD • WaveReadThread in CFeederClient • Pops voicename requests off a queue, and downloads the file & saves to disk. • Writes the change to SQL, then pushes the change onto DirSynker queue
Mapping Cxn Location Attributes to Unity When the Unity Reader imports a Connection Location, it maps Cxn Info Feed attributes to Unity SQL data. Some are non-trivial.
Mapping Cxn User Attributes to Unity When the Unity Reader imports a Connection User, it maps Cxn Objects Feed attributes to Unity SQL data. Some are non-trivial. • Note that other attributes will follow the SubscriberTemplate chosen in Unity SA.
Mapping Cxn DL Attributes to Unity When the Unity Reader imports a Connection DL, it maps Cxn Objects Feed attributes to Unity SQL data. Some are non-trivial.
A Note on Imported Distribution Lists When the Unity Reader imports a Connection Distribution List, it actually creates 2 objects. • A DistributionList object (stored in the SQL DistributionList table) • An internal/hidden DL Contact object (stored in the SQL Subscriber table) Since we don’t import Distribution List membership from Connection, the Unity DL object representing the Cxn DL contains only this internal DL Contact object. A Unity user may address to the DL object like any other Unity DL (same scoping rules, etc.). But messages sent to it are routed through the internal DL Contact object. The Connection SMTP network is responsible for routing the message to the recipients. A DL Contact alias is prefixed with “UCIDL_” rather than “UCI_”.
Importing Connection Extensions • For each User or DL that Unity imports from Cxn, it must classify all extensions as Primary, Alternate, Duplicate, or Out-of-Partition • First, any Extension whose UnityPartitionObjectID does not match the one defined for the Location is marked as Out-of-Partition, and thus not imported. • Next, of the remaining Extensions, any Extension that conflicts with an existing Extension is marked as Duplicate, and thus not imported. • Finally, the remaining Extensions are sorted in order by Index. The one with the lowest Index is the Primary Extension, and all others are Alternates. • Note the following consequences of this classification algorithm: • It is quite possible that all Extensions for an imported User or DL will be either Out-of-Partition or Duplicate, and thus not addressable by DTMF. • If multiple Cxn Objects have the same Extension defined, the one at the lowest USN will get it (can appear random to the Admin). • If a Cxn Object’s Primary Extension is a Duplicate or Out-of-Partition, then his Primary Extension on Unity will be one of his Alternate Extensions from Cxn. • Reason for this complexity: Cxn has Calling Search Spaces and Partitions, but Unity does not. • Cxn Admin can define a Unity Partition and create unique Alternate Extensions
Authentication and Verification • The Feeders require Authentication before they will serve the Objects Feed. The Feeder returns HTTP 4xx if Auth fails. • The Feeders Sign the Objects Feed and VoiceNames when serving them, and the Readers must Verify those Signatures. • Both Unity and Connection create Authentication Certificates, and they share their public keys during the Join process. • Authentication of the Objects Feed is to ensure that an unauthorized entity can’t access confidential directory information. • Signing the Objects Feed and VoiceNames is to ensure that an unauthorized entity can’t modify them (man-in-the-middle). • Standard RSA public-key encryption with 2048-bit keys is used for both Authentication and Signing/Verification. • This is independent of whether HTTPS or HTTP is used between Unity and Connection, and note that HTTPS also uses different certificates than are used here.
SQL Changes There are several new SQL tables to support the Reader • InteropFeeder: One row per Connection Feeder (limited to 1 row in Unity 8) • Triggers on SQL table notify Reader of config changes, resynk requests, etc. • Data includes: Machine Name, IP Addr, SSL Settings, Feed-Read Interval, Cxn Authentication Cert, LastUSN, Object & Change Counts, and if DLs and VoiceNames should be requested. • InteropCertificate: Contains the Unity Authentication Cert (singleton). • InteropLocation: For Cxn Site Gateway, this links its row in the Location table to the InteropFeeder that correponds to it. Also stores the Unity Partition ObjectID. • InteropSubscriber: Adjunct to Subscriber table; stores the VoiceName filename, and whether it’s a DL Contact. • InteropExtension: Stores all extensions for Cxn users and lists; used to determine which are primary, alternate, duplicate, and out-of-partition. • FailedUSN: When the Reader is stopped or paused, this stores the USNs which should be requested when it starts back up (retry queue). • PendingVoiceName: When the Reader is stopped or paused, this stores the VoiceNames which should be requested when it starts back up.
Troubleshooting • The Unity Reader is a reasonably complicated component and can encounter problems in several areas: • Responding to Config Changes and Resynk Requests • HTTP[S] Reads of the Cxn Info and Objects Feeds • HTTP[S] Reads of Cxn VoiceNames • Authentication & Verification of Objects Feed & VoiceNames • Reading from and Writing to SQL • Writing to Active Directory
Troubleshooting Techniques There are a number of methods that can be used and interfaces that can be examined to diagnose problems: • Application EventLog messages • Unity diagnostic traces • Using a web browser to access the feeds • Looking directly at SQL tables • Looking directly at Active Directory objects • Examining installed certificates • Tweaking throttling parameters • Doing a Resynk • Unjoining and rejoining the network • Troubleshooting the Connection Feeder (a different TOI)
Diagnostic Traces The Unity Reader has several micro trace levels in the CuDirReader category in Unity Diagnostic Tool (UDT): • 0 = High Level Methods Entry/Exit of the major/interface functions • 1 = Mid Level Methods Entry/Exit of secondary functions • 2 = Low Level Methods Entry/Exit of low-level functions (can be spammy) • 3 = Errors All serious failures (HTTP, Auth, SQL, AD, etc.) • 4 = Warnings Non-fatal but notable events • 5 = Information General Explanatory traces • 6 = XML Documents The entire raw Info & Objects Feeds • 7 = Dump Objects The parsed representation of the Info & Object Feeds • 8 = SQL Queries Every SQL ad-hoc query & sproc • 9 = DbSync to AD Every attempt to write to AD • 10 = Security and Authentication Details of Authentication & Verification These all appear in the diag_CuDirReader_* log file. Enabling all trace levels except level 2 will provide good all-around tracing. Note that the log file might be large on the initial synk!
Unlocking Objects Feed • By default, the Objects Feed requires Authentication, but you can unlock it so that it can be viewed in a web browser. • Authentication of Connection’s Objects Feed is controlled by the bypassAuthentication flag in the Feeder’s web.xml. • A quick method to unlock it: login into the shell as root, and type sed -i s/false/true/ $CATALINA_HOME/webapps/feeder/WEB-INF/web.xml • Reverse the false and true in the sed command to lock it back up. • Authentication of Unity’s Objects Feed is controlled by the SQL value InteropFeeder.UseAuth. Via SQL Management Studio, change it to false to unlock it, and change it back to true to lock it back up. • Once the Objects Feed is unlocked, you can specify the URL command arguments previously discussed (start, end, objectsType, etc.) when typing the URL into the web browser. • Example: https://sea-vm-ks-10/feeder/objects?start=100&objectType=user • Note that normal directory synk operation will fail if Authentication is only disabled in one direction, so make sure to unlock both, and lock it back up after troubleshooting is completed.
EventLog Messages • The Reader has many EventLog Messages such as: • Service starts and stops, indicating success or failure • Joins to and unjoins from a Cxn Feeder • Pausing and resuming the read from a Cxn Feeder • Failure to read from the Info or Objects Feed • Failure to write a location or object to SQL or AD • Warning about duplicate extensions • Failure to download a VoiceName • Failure to Sign an Objects Feed Request or Verify the Feed or a VoiceName • Warning if the previous service stop was not graceful (service crash or system failure), since the directory information might be inaccurate in that case • An error message if the Cxn Site Gateway has changed. It cannot be changed without doing a network unjoin and then a rejoin to the new Site Gateway.
SQL InteropFeeder Table View the InteropFeeder Table with SQL Management Studio.
Finding Cxn Locations in AD Cxn Location DisplayName Cxn Location DialID Type 10 = Cxn Networking Unity Site Gateway isCxn Location Home Server Cxn Server IP Address • Run LDP.exe • Do File\Bind, then View\Tree. • Expand Root > Unity OU >Locations OU. • Unity & Cxn Locationsshould be visible.
Similar to prev slide, but Expand Users node Finding Cxn User in AD Cxn User DisplayName Cxn User Target Address Cxn User Alias Cxn User Extensions
Viewing Public Keys in SQL The Public Keys for Unity and Cxn are stored in SQL (base64 encoded). The complete Unity certificate (including Private Key) are stored in the OS cert store (next slide). Local Unity Cert Remot e Cxn Cert
Viewing Local Cert in OS Store This is expected –we use self-signed certs. If no Private Key, you’veprobably got a permissions problem with the account. • Run mmc.exe • Do File\Add/Remove Snap-in • Add Certificates for the Local Computer Account • Expand the Certificates node • Right-click Open on the cert
Reader Throttling Parameters The Unity Reader has several throttling parameters in SQL in the Configuration Table – 4 groups of 2 parameters. Defaults: Pause 50 ms after each operation (object parse, SQL write, AD write, or voicename synk) These parameters are not exposed via a GUI since they should rarely if ever need to be adjusted.
Unity Resynks • By default, Unity will do pull directory changes every 15 minutes. • In Unity SA, you can request immediate resynks of several types: • “Synk Now”: Synk from high-water mark USN immediately (rather than wait til the next 15 minutes interval) • “Total Synk”: Synk starting from USN 0 immediately, which means all Connection objects will be pulled, not just the recently change ones. • “Clear Voice Names”: This will delete all imported voicenames, and clear Unity’s cache of their filenames (SQL InteropSubscriber.ImportedVoiceName). • A normal “Total Synk” will only pull down an object’s voicename if it has changed. The Objects Feed lists the filename, and Unity will only pull down the voicename if the filename has changed. So, if you want to also pull down all voicenames when you do a “Total Synk”, you must first do a “Clear Voice Names” before doing the “Total Synk”.
Unjoining & Deleting a Network • Once a Unity Connection Network has been joined, it can later be unjoined. This will do the following: • The Reader will begin deleting all imported users and DLs from SQL and AD. • The Reader will write informational messages to the eventlog when it starts deleting the objects and when it’s done doing so. • Once all of the objects are deleted, the un-join is complete. • Once the Network is unjoined, you can do the following: • Make configuration changes such as disabling synking of DLs • Delete the Network. • Re-join the Network. • The reason for the distinction between unjoining and deleting a network is so that cross-box settings can be retained in can you later want to re-join. Cross-box settings to the Cxn locations are deleted if you delete the network.
Diagnostic Log File Examples • The next few slides will show annotated diagnostics from the Unity Reader service. • An earlier slide described what the various traces levels are for. In these examples, all trace levels except level 2 are enabled. • For brevity and readability, the trace output has been edited to remove the less pertinent information. • Recall that there are several threads involved in reading objects from Connection and writing them to SQL & AD, so following an object thru the diagnostic log file can be tricky. • Hints: Search for the USN, ObjectID, and/or Alias. • To simplify things, the examples will break up the threads rather than have them interwoven. • Excerpts from the SqlSync_*.txt logfiles are included as well, to show more details on the synks to AD.
Start of a Feed Read Log for Info Feed Read First, Info Feed is Read Server Name and URL 14:24:29:296 [1112] CFeederClient::ReadFromFeeder entered 14:24:29:297 [1112] CFeederClient::ReadInfo entered 14:24:29:297 [1112] CFeederClient::GetXmlDoc: Attempting to read XML Document from Feeder 'sea-vm-ks-10' (sea-vm-ks-10.cisco.com:0) at Url '/feeder/info' 14:24:44:406 [1112] CFeederClient::SendRequestAndReceiveResponse: ServerHeaders: 'HTTP/1.1 200 OK ... ‘ 14:24:44:406 [1112] From Feeder 'sea-vm-ks-10' (sea-vm-ks-10.cisco.com:0) - Retrieved XML Document (size 2736) from URL /feeder/info 14:24:44:407 [1112] <?xml version='1.0' encoding='UTF-8'?> 14:24:44:406 [1112] <info maxObjectsPerRequest='500' product='Unity Connection/8.0.0.270'> <rest of raw info feed> 14:24:44:406 [1112] </info> 14:24:44:407 [1112] CFeederClient::ReadInfo exited with 0x00000000 14:24:44:406 [1112] CFeederClient::ParseInfo entered 14:24:44:422 [1112] Dumping Info Feed for '2010-01-22 14:24:44' (MaxObjs=500 Product=Unity Connection/8.0.0.270 Version=1.0) <rest of parsed info feed> 14:24:44:422 [1112] CDirInfo::Parse exited with 0x00000000 14:24:44:421 [1112] CDirWriter::PushLocation entered 14:24:44:422 [1112] CDirWriter::PushLocation exited with 0x00000000 14:24:44:438 [1112] CFeederClient::ParseInfo exited with 0x00000000 HTTP 200 OK = SUCCESS Dump of Raw Info Feed Raw Info Feed is Parsed Dump of Parsed Info Feed Push Location to DirWriter Done Reading Info Feed
Start of Object Feed Read Log for Objects Feed Read Server Name and URL Sign Request with Unity Cert & Hash of URL 14:24:44:437 [1112] CFeederClient::ReadObjects entered 14:24:44:437 [1112] CFeederClient::GetXmlDoc: Attempting to read XML Document from Feeder 'sea-vm-ks-10' (sea-vm-ks-10.cisco.com:0) at Url '/feeder/objects?objectType=user&rs=e82c3c01-cbec-4c98-87c9-0c25521a0b30' 14:24:44:438 [1112] CReadAuthenticator::Sign entered 14:24:44:437 [1112] CReadAuthenticator::Sign: calling IAuth::Sign(LocalCert 'MIICuj...' Hash '23-EF...') 14:24:44:438 [1112] CReadAuthenticator::Sign: Signature from IAuth::Sign is 'ak7v...' 14:24:44:437 [1112] CReadAuthenticator::Sign exited with 0x00000000 14:24:44:437 [1112] CFeederClient::SetRequestOptions: Assigning Auth Headers 'X-Cisco-Authenticator-Identity: EKV-W2K3-1 X-Cisco-Authenticator: ak7v... X-Cisco-Authenticator-Salt: Oa9a...' 14:24:44:593 [1112] CFeederClient::SendRequestAndReceiveResponse: ServerHeaders: 'HTTP/1.1 200 OK ...' 14:24:44:594 [1112] CFeederClient::SendRequestAndReceiveResponse: Signature='rVoX...' Salt='SnkD...' 14:24:44:593 [1112] CReadAuthenticator::Verify entered 14:24:44:594 [1112] CReadAuthenticator::VerifyInternal: calling IAuth::Verify(PublicCert 'MIIC3z...' Hash 'F1-40...' Signature 'rVoX...') 14:24:44:734 [1112] CReadAuthenticator::VerifyInternal: IAuth::Verify(2528 bytes) returned a signature match 14:24:44:735 [1112] CReadAuthenticator::Verify exited with 0x00000000 14:24:44:734 [1112] CFeederClient::DownloadAndVerifyResponse: Authentication succeeded Signature is Generated Add Auth Headers to Request HTTP 200 OK = SUCCESS Extract Signature & Salt Verify Response with CxnCert, Hash of Data, & Sig Signature is Verified Authentication Succeeded!
Dumping Raw Objects Feed Log for Objects Feed Read (part 2) 14:24:44:734 [1112] From Feeder 'sea-vm-ks-10' (sea-vm-ks-10.cisco.com:0) - Retrieved XML Document (size 2528) from URL /feeder/objects?objectType=user&rs=e82c3c01-cbec-4c98-87c9-0c25521a0b30 14:24:44:735 [1112] <?xml version='1.0' encoding='UTF-8'?> 14:24:44:734 [1112] <objects lastUsn='41' maxObjectsPerRequest='500' numObjects='2' product='Unity Connection/8.0.0.270'> 14:24:44:735 [1112] <object id='710cfdf0-62a0-415f-ba8f-40b7ef39bd19' type='user' usn='25'> 14:24:44:734 [1112] <a name='alias' value='undeliverablemessagesmailbox'/> <rest of raw objects feed> 14:24:44:735 [1112] </objects> 14:24:44:734 [1112] CFeederClient::ReadObjects exited with 0x00000000 14:24:44:735 [1112] CFeederClient::ParseObjects entered 14:24:44:796 [1112] CDirWriter::PushDirObject entered 14:24:44:797 [1112] CDirWriter::PushDirObject exited with 0x00000000 14:24:44:796 [1112] CFeederClient::Throttle: Pausing 50 milliseconds every 1 objects <rest of objects parsed> 14:24:44:843 [1112] CFeederClient::ParseObjects exited with 0x00000000 14:24:44:875 [1112] CFeederClient::ReadFromFeeder: sea-vm-ks-10 (sea-vm-ks-10.cisco.com:0) - ObjectsParsed=2 TotalParsed=2 14:24:44:876 [1112] CFeederClient::ReadFromFeeder exited with 0x00000000 Begin Parsing Objects Feed Push Object to DirWriter Throttling – 50 ms after each Feed Read Complete
DirWriter Thread wakes up Log for Writing Location to SQL Pops an Object off its Queue Dumps Parsed Location 14:24:44:438 [7952] CDirWriter::WriteData entered 14:24:44:437 [7952] CDirWriter::PopSynkObject entered 14:24:44:438 [7952] CDirWriter::PopSynkObject exited with TRUE 14:24:44:437 [7952] Dumping Location: Name=sea-vm-ks-10 Id=86e3d148-551a-4f8c-bd33-d5d3275fd05b HostAddr=10.93.236.29 SmtpDomain=sea-vm-ks-10.cisco.com Bridgehead=TRUE Version=1.0 DialID=BH-E08E 14:24:44:437 [7952] CObjWriter::WriteLocation entered 14:24:44:453 [7952] CObjWriter::ObjectExists: Calling SProc sp_FindLocationByGuidString(@strGuid=86e3d148-551a-4f8c-bd33-d5d3275fd05b) 14:24:44:454 [7952] CObjWriter::ModifyLocation: Executing Ad-hoc Query 'SELECT DefaultPartitionObjectId FROM InteropLocation WHERE LocationObjectId=?' (Params '86e3d148-551a-4f8c-bd33-d5d3275fd05b') 14:24:44:453 [7952] CObjWriter::ModifyLocation: Calling SProc csp_LocationModify(@LocationObjectId='86e3d148-551a-4f8c-bd33-d5d3275fd05b' @SmtpDomain='sea-vm-ks-10.cisco.com' @Alias='sea-vm-ks-10' @TextName='sea-vm-ks-10' @HomeServer='EKV-W2K3-1' @DefaultPartitionObjectId='251e317e-5d7d-468c-b0b4-5d8060a96cd4' @RemoteServer='10.93.236.29' ) 14:24:44:468 [7952] CObjWriter::WriteLocation exited with 0x00000000 14:24:44:468 [7952] CDirSynker::PushLocation entered 14:24:44:469 [7952] CDirSynker::PushLocation exited with 0x00000000 14:24:44:468 [7952] CDirWriter::PopSynkObject entered 14:24:44:469 [7952] CDirWriter::PopSynkObject exited with FALSE 14:24:44:468 [7952] CDirWriter::WriteData exited with 0x00000000 Checks if it’s an Add or Modify Check if Partition Changed Call csp_LocationModify Push Location to DirSynker No more Objects in Queue DirWriter is done for now
DirSynker Thread wakes up Log for Writing Location to AD Pops an Object off its Queue Synks the Location to AD 14:24:44:469 [6988] CDirSynker::SynkData entered 14:24:44:468 [6988] CDirSynker::PopSynkObject entered 14:24:44:469 [6988] CDirSynker::PopSynkObject exited with TRUE 14:24:44:469 [6988] CDirSynker::SynkOneLocation: Synking LocationID=86e3d148-551a-4f8c-bd33-d5d3275fd05b (Name=sea-vm-ks-10 HostAddr=10.93.236.29) to AD 14:24:44:797 [6988] CDirSynker::SynkOneLocation exited with 0x00000000 14:24:44:796 [6988] CDirSynker::PopSynkObject entered 14:24:44:797 [6988] CDirSynker::PopSynkObject exited with FALSE 14:24:44:796 [6988] CDirSynker::SynkData exited with 0x00000000 No more Objects in Queue DirSynker is done for now
Synk Starts (0x8 = Location) SqlSync Log for Writing Location Location Synk Starts Fri Jan 22 14:24:44.468 CDbSync::SyncCommit Called. ulSyncItems: 0x8 \DbSync.cpp (line 279) Fri Jan 22 14:24:44.468 Entering SyncLocations \DbSync.cpp (line 396) Fri Jan 22 14:24:44.484 Synking Location sea-vm-ks-10 \DbSync.cpp (line 461) Fri Jan 22 14:24:44.640 Found object in GC by DirectoryId. \ConnectorClientBase.cpp (line 342) Fri Jan 22 14:24:44.640 Found Object in Domain DOM-EKV-W2K3-1.sea-alpha-ucbu.cisco.com \ConnectorClientBase.cpp (line 248) Fri Jan 22 14:24:44.656 No voice name data for object. \DbSync.cpp (line 1912) Fri Jan 22 14:24:44.671 Entering ModifyDirObject \ConnectorClientBase.cpp (line 512) Fri Jan 22 14:24:44.765 Exiting ModifyDirObject \ConnectorClientBase.cpp (line 529) Fri Jan 22 14:24:44.796 Exiting SyncLocations, returning 0x0 \DbSync.cpp (line 628) Location Exists – Modify it Location Modify Done Location Synk Succeeds
DirWriter Thread wakes up Log for Writing User to SQL Pops an Object off its Queue Throttling between SQL Writes 14:24:44:797 [7952] CDirWriter::WriteData entered 14:24:44:796 [7952] CDirWriter::PopSynkObject entered 14:24:44:797 [7952] CDirWriter::PopSynkObject exited with TRUE 14:24:44:796 [7952] CDirWriter::Throttle: Pausing 50 milliseconds every 1 objects 14:24:44:843 [7952] Dumping Object (Type=0=User Action=0=Add ID=710cfdf0-62a0-415f-ba8f-40b7ef39bd19 USN=25 Version=1.0 Feeder=sea-vm-ks-10.cisco.com:0) 14:24:44:843 [7952] Attr alias=undeliverablemessagesmailbox <rest of parsed object> 14:24:44:844 [7952] CObjWriter::WriteObject entered 14:24:44:875 [7952] CObjWriter::IsUserFromUnity: Executing Ad-hoc Query 'SELECT SubscriberType FROM ObjectChange WHERE ObjectId=?' (Params '710cfdf0-62a0-415f-ba8f-40b7ef39bd19') 14:24:44:876 [7952] CObjWriter::ObjectIdMatchesMapping: Executing Ad-hoc Query 'SELECT FeedObjectId FROM InteropMapping WHERE FeedObjectId=?' (Params '710cfdf0-62a0-415f-ba8f-40b7ef39bd19') 14:24:44:875 [7952] CObjWriter::DiginetOidMatchesMapping: Executing Ad-hoc Query 'SELECT Timestamp FROM InteropMapping WHERE DiginetObjectId=?' (Params '710cfdf0-62a0-415f-ba8f-40b7ef39bd19') 14:24:44:876 [7952] CObjWriter::DiginetOidMatchesObjectChange: Executing Ad-hoc Query 'SELECT IsDeleted IsMoved FROM ObjectChange WHERE ObjectId=?' (Params '710cfdf0-62a0-415f-ba8f-40b7ef39bd19') 14:24:44:875 [7952] CObjWriter::WriteObject: USN=25 (DisplayName=Undeliverable Messages ObjectID=710cfdf0-62a0-415f-ba8f-40b7ef39bd19 DiginetOid=710cfdf0-62a0-415f-ba8f-40b7ef39bd19) was not found in the InteropMapping or ObjectChange Tables - performing create. Dumps Parsed User Several SQL Queries to check if Add, Delete, Modify, Migrate Object not found – Create it
Duplicate Extension found Log for Writing User to SQL (part 2) Extension added to SQLInteropExtension table 14:24:44:937 [7952] CObjWriter::PreprocessExtensions: ObjectID=710cfdf0-62a0-415f-ba8f-40b7ef39bd19 (DisplayName 'Undeliverable Messages') - Extension 99999 is already used by another object (Name='Example Administrator - EKV-W2K3-1' ObjId='3D8D9467-F8D7-4E9F-A01E-1FB274AC04D9') 14:24:44:938 [7952] The Cisco Unity service that synchronizes directory information with a Cisco Unity Connection Network (CuDirReader) encountered a duplicate extension for an imported object from the Feeder 'sea-vm-ks-10 (sea-vm-ks-10.cisco.com:0)'... 14:24:44:937 [7952] CObjWriter::PreprocessExtensions: Executing Ad-hoc Query 'INSERT INTO InteropExtension (InteropExtensionObjectId LocationObjectID ParentObjectID Extension PartitionObjectID ExtensionIndex ParentObjectIdType) VALUES (? ? ? ? ? 0 1)' (Params 'a81e18ad-1e76-4a78-af0a-e244cbf32f42' '86e3d148-551a-4f8c-bd33-d5d3275fd05b' '710cfdf0-62a0-415f-ba8f-40b7ef39bd19' '99999' '251e317e-5d7d-468c-b0b4-5d8060a96cd4') 14:24:44:953 [7952] CObjWriter::ObjectExists: Calling SProc sp_FindLocationByGuidString(@strGuid=86e3d148-551a-4f8c-bd33-d5d3275fd05b) 14:24:44:954 [7952] CObjWriter::CreateUser entered 14:24:44:969 [7952] CObjWriter::ConstructRemoteAddress: RemoteAddress='UCI:BH-E08E_710cfdf0-62a0-415f-ba8f-40b7ef39bd19' for GatewayAddress='710cfdf0-62a0-415f-ba8f-40b7ef39bd19@sea-vm-ks-10.cisco.com' at Location='86e3d148-551a-4f8c-bd33-d5d3275fd05b' (DialID='BH-E08E') Ensure Location Exists Construct the RemoteAddress Based on Feed Data
sp_CreateInteropSubscriber Log for Writing User to SQL (part 3) Check if VoiceName changed 14:24:44:968 [7952] CObjWriter::CreateSubscriber: Calling SProc sp_CreateInteropSubscriber(@SubscriberObjectId='710cfdf0-62a0-415f-ba8f-40b7ef39bd19' @SubscriberTempId='60A04B26-8DEC-4249-9B8A-9CEC3FB1133E' @XferString=NULL @LocationObjectId='86e3d148-551a-4f8c-bd33-d5d3275fd05b' @ListInDirectory='0' @HiddenInDirectory='0' @Alias='UCI_undeliverablemessagesmailbox_BH-E08E' @RemoteAddress='UCI:BH-E08E_710cfdf0-62a0-415f-ba8f-40b7ef39bd19' @LastName=NULL @FirstName=NULL @DisplayName='Un deliverable Messages - Voicemail' ) 14:24:47:937 [7952] CObjWriter::CheckVoiceName: Executing Ad-hoc Query 'SELECT ImportedVoiceName FROM InteropSubscriber WHERE SubscriberObjectId=?' (Params '710cfdf0-62a0-415f-ba8f-40b7ef39bd19') 14:24:47:938 [7952] CObjWriter::CheckVoiceName: User 'Undeliverable Messages' (ObjectID=710cfdf0-62a0-415f-ba8f-40b7ef39bd19 USN=25) - VoiceName='' has not changed 14:24:47:937 [7952] CObjWriter::CreateUser exited with 0x00000000 14:24:47:937 [7952] CObjWriter::WriteObject exited with 0x00000000 14:24:47:937 [7952] CDirSynker::PushDirObject entered 14:24:47:938 [7952] CDirSynker::PushDirObject exited with 0x00000000 14:24:47:937 [7952] CDirWriter::PopSynkObject entered 14:24:47:938 [7952] CDirWriter::PopSynkObject exited with TRUE <repeat for next object> Done Writing User to SQL Push Object to DirSynker Pop next Object off Queue