zettelkasten/03_Seite 3.md at 1c55243740c1c213220774b12d4118d031ff4b4b - zettelkasten - Ralf's Git

ralfk/zettelkasten

Ralf Koop 7389e600f9 vault backup: 2023-11-12 11:19:55

Affected files:

2023-11-12 11:19:55 +01:00

4.1 KiB

Raw Blame History

Seite 3

Freitag, 15. Januar 2016

19:45

$Computergenerierter Alternativtext: · Determine the suspected server from the RPC popup. The specific server will be listed and can include the user's home Exchange server, an Exchange server the user was referred to for public folders, another user's home Exchange server in the case of Calendar Details in the F/B UI, shared calendar/shared folder, or in delegate access, and Active Directory Servers. · Collect Exmon ETL data via one of the supported methods. Consistent problems may need only 5 minutes worth of data collection to trace the event. It is important to trace for a period afterwards to allow collection and tracing by the Exchange server. Outlook buffers some monitoring data until its next server communication. Problems that happen sporadically may require multiple hours or days' worth of collection. ETL file size and server impact is documented in the Frequently Asked Questions. · Open the ETL data file with the Exmon tool. · Verify that the user made RPC calls and those calls were traced. Find the user's display name in the By User view. If the Exchange Server is Exchange 2003 or higher, verify that the IP address of the client appears as the IP address of the client machine in question. If the user's display name does not appear in the By User view, an RPC call may have been issued and received by Exchange, but no successful Logon operation from that user was received (and thus could not be attributed to any user). Alternatively find the "" (BLANK) user name in the By User view and look for the user's IP Address. If the IP Address appears in this list, an RPC was received by the Exchange server, but the Logon call failed. · See if any MAPI operations took longer than 500 milliseconds . Within the By User View, the Max Server Latency will indicate the longest time spent processing a single MAPI operation, but an RPC could contain multiple operations. · If the Max Server Latency is above 500 milliseconds , double click on the user's name in the By User view. This will cause a reparse of the ETL file (which can take minutes for extremely large files) and will eventually display a detailed view of the user's MAPI operations. Find the time frame in question (we have accuracy to about 15 milliseconds) in the By Time view. Verify if other operations took a long amount of time that would have been in the same packet or in packets within close range. It is prudent at this point to verify disk latencies are acceptable within the guidelines given in the Exchange Performance Tuning Whitepaper since the overall latency is determined both by the CPU and Store processing, as well as the timeliness of Jet database accesses by the disk subsystem. · If roughly 5000 milliseconds cannot be accounted for, network latency may be involved . Check the By Clientmon view (if you're using both Exchange 2003 and higher and Outlook 2003 and higher) for high max and/or average latencies. Using the By Clientmon view, find the user in the list and verify the user's IP Address is in the list of IP Addresses. If the IP Address of the client is not in the user's IP Address list, it is possible no client monitoring data was received. Check both the local and other average and max latencies. High average latencies could indicate an overall bad network condition. If the average is acceptable, the max latencies could be high on account of a momentary network issue or because of a long running MAPI operation. Remember, these latencies are the total round trip time of the packet including network transit and store latencies. · If latencies are acceptable, check for failed RPC Packets. Failures happen from time to time and do not always indicate a problem, but are a useful step. · Look out for IP Addresses reported in the By Clientmon view (IP addresses that Outlook thinks it is using based on the NIC/VPN) that differ from the IP Addresses in the By User view (IP address as Troubleshooting Microsoft Exchange: Outlook Connectivity Issues -\... http://blogs.technet.com/b/mspfe/archive/2011/04/12/troubleshooti\... 3 von 1115.01.2016 19:44$ {width="8.333333333333334in" height="11.75in"}

#nochzubearbeiten