Neal's Admin.Notes.

Exchange 2007 Legacy Mailbox to User Mailbox

If you mistakenly create a mailbox user with ADUC ( Active Directory Users and Computer ) you will notice that the mailbox you created for that user is a tagged as a legacy mailbox. You will loose some features of Exchange 2007 in this mode. To fix this you need to remove the legacy tag in Exchange 2007. The following cmdlet will make it a User Mailbox when you run it in Exchange Shell.

Set-Mailbox -Identity "alias" -ApplyMandatoryProperties

Just change "alias" with the mailbox name or the alias and keep the quotations on it.

How to get Mailbox Size in Exchange 2007

Getting mailbox size info is very different from the simple list view in previous Exchange versions. However if you take some time and use the Powershell/Console, you can extract all the information you need.
Here is a niffty command that you can use to generate a report that will give you some statistics on your users mailbox sizes. It requests information on mailboxes greater than 1 MB and outputs the data to a txt file. You can however modify it with other various shell commands.


Get-MailboxStatistics |where {$_.TotalItemSize -gt 1MB} | sort $_.TotalItemSize |FT DisplayName,ItemCount,TotalItemSize >c:\size.txt

How do undersea cable repeaters work, and how are they powered?

Undersea cables use an armorless coaxial cable design. The repeaters have a rigid housing and directional filters which permit transmitting in both directions through one cable and a single amplifier in each repeater. The lower portion of the transmission band goes in one direction, the higher portion in the other direction, with an unused guard-band between the two. Each repeater contains anoscillator with a unique frequency, which is used for fault location and to determine gains and losses along the length of the system. Those repeaters are powered in series, through the center conductor, from the two ends. Ideally, the gain of each repeater would exactly compensate, at each frequency, for the loss of the associated cable.There will be small differences between average repeater gain and average cable loss, as well as variations from repeater to repeater and cable section to cable section. Both of these types of variations lead to deviations from the actual zero net gain of a cable and its associated repeater. Any such differences between these gains and losses have a signal-to-noise penalty associated with them, which is roughly a function of the total net gains and losses between any two repeaters. To hold these penalties to an acceptable level (a few decibels, ocean block equalizers are inserted at regular intervals along the system (every 20 or 30 repeaters). These equalizers are passive; they use gain from an adjacent repeater which has much less than a full cable section associated with it (in the case of SG, 1 nmi rather than 5 nmi). These equalizers contain fixed networks to compensate for deviations known at the time the equalizers are manufactured. They also contain a family of networks that can be switched in or out just prior to the laying of each equalizer to compensate for deviations that first become apparent, as the system is layed. It is the determination and setting to the optimum choice among the available networks for each equalizer that is the most important transmission function during laying. To make it simple, underwater repeaters are powered by high voltage dc power supplies established at the shore terminals. Each repeater and equalizer contains a power separator filter for extracting the dc current from the center conductor of the coaxial cable while allowing signal transmission.

Calculating real-time throughput between endpoints in a LAN.

Iperf is a program designed for the purpose of measuring TCP and UDP bandwidth. Iperf uses a client/server model for testing. For the purposes of your test, you'd set up a PC at one of the endpoints with iperf as a server, and at the other end, you'd use iperf as a client.

When run in UDP mode, iperf is testing the maximum amount of bandwidth between the client and a server. iperf provides a few different sections of output. These sections are the incremental output, the summary output, and the server output. The incremental output is useful as it shows you that yes, the program is in fact running, along with its current output speeds. The summary output shows the summary of the entire test - how much data was pushed and at what speed. The server output shows how much data the server received, and the rate at which it was received (which is calculated based on the total amount of data received, divided by the time of the test from start to finish). The server output is critical for UDP testing since UDP has no guarantee of delivery.

What does this mean to you? You need the summary output to be able to tell how fast the machine you were running the test from was able to generate traffic. This is critical as if the machine can't generate sufficient traffic, then we aren't testing the full capacity of the link, which is what we are trying to do. On the other hand, you can't use the summary results to tell you how the link tested, since its just reporting how much data it was able to dump and not how much data was received. Thats where the server summary output comes into play. The server summary tells you how much data arrived at the server, and then calculates the rate (or bandwidth used) by dividing that number by the amount of seconds used in the test.

So if you are doing a 100mbit test (FastE speeds), but have only a DS3 (45mbit) between your host and the server, while the summary output may tell you 90mbit/sec, the server is only going to tell you 40-43mbit/second. The other traffic was discarded by the router since the link (DS3) was full and there was no buffer space. Such is how UDP works, being connectionless, stateless, and having no guarantee of delivery.

When run in TCP mode, iperf is testing the total throughput of the connection - how quickly you will be able to push data via TCP across the link, from client to server. This differs from the total bandwidth available, since TCP is a connection oriented and stateful protocol, with error correction. Every packet sent needs to be ack'd, and only so many packets will be sent before the sender starts holding packets until it receives acks.

Output from a TCP test is similar to the UDP test, however, you only have the incremental and summary output; TCP being TCP, the client is able to determine how many packet drops there were by how many retransmits it needed to perform.

When testing, be sure to use the -d (dualtest, do bidirectional testing simultaneously) or the -r (dualtest, do bidirectional testing sequentially) options, so you are measuring available bandwidth in both directions (it isn't always the same).