If a browser is configured to detect proxy server settings automatically, the proxy server address is never displayed anywhere in the browser. You may have an application, however, that requires you to explicitly define the proxy server to use. To determine the server to use, you can use PowerShell. (You can’t do it as a one-liner because the System.Net.WebClient class doesn’t have any static methods, which means you have to load the class before you can call any of the methods.)
$webclient = new-object System.Net.WebClient
$webclient.Proxy.GetProxy("http://www.cnn.com").Authority
The URL to use in the query can be anything as long as it is one that will evaluate to using a proxy server, so don’t use an internal address that will evaluate to connecting directly. The query will return the DNS name of the proxy server and the port to use, e.g., proxy.company.com:8080. If you want these values separately, you can use the Host and Port properties.
There are a couple of changes that have been made to improve the script.
First, after running a report for a user with thousands of messages and not having any idea of the progress while it was running, I added progress windows during the two phases (content conversion and HTML report creation). The progress window will tell you how many messages will be processed and how far along it is in that process.
Second, I discovered that hyperlinks in messages were not showing up in the report. Looking at the HTML (or XML) source, I could see the link was there, but the way it was formatted in the XML file (using element enclosures) meant the conversion to HTML was confusing the parser. Now I remove those characters prior to the link being written to the XML file.
I also optimized the message body conversion loop to remove redundant or obsolete code that was in the original script. There are also some minor cosmetic changes here and there.
Lastly, I realized last week that the script only reports on peer-to-peer (P2P) conversations, not multiparty. I spent some time trying to get multiparty conversations out of the database, but it is proving much more difficult than I anticipated. The format of multiparty IMs in the archiving database is very different than P2P conversations. I am still working on it, but I am not sure I will be able to make it work. In the meantime, I added a note in the report that states it is only for P2P conversations.
The original zip file with the script has been updated, but you can download it here:
Get-ArchivingData.zip (3.1 KiB)
Comments (1) 
Themocracy