Blocking Unwanted SMS Spam from AOL

Summary:

I started receiving unwanted SMS spam from 265080.  These messages can be stopped by blocking yourself on the AOL SMS servers.

Details:

Go to http://aolmobile.aol.com/portal/blockim2sms.do and register your phone number.  They'll send you a quick confirmation text message - which should hopefully stop unwanted SMS messages through their gateway.

Seems quite silly to have that enabled by default on all numbers - a bad default policy I think.

No longer annoyed when I close the wrong program by accident

Summary:

SSDs are really fast.  You should get one.

Details:

I finally caved and got an Intel 160GB G2 SSD for my laptop.  Photoshop opens within 4-5 seconds (I don't actually USE Photoshop, but I installed it just to see how fast it was.)  Outlook opens within 1s.  Virtually everything else opens instantly.  Makes my computer a pleasure to use again.

Understanding Windows Time Synchronization in 30 Seconds

Select a time source:

Stratum 2: https://support.ntp.org/bin/view/Servers/StratumTwoTimeServers
Pool: https://support.ntp.org/bin/view/Servers/NTPPoolServers
I've used pool.ntp.org and an NRC server in Canada below.

Standalone machine:

w32tm /config /syncfromflags:manual /manualpeerlist:"pool.ntp.org time.nrc.ca"
w32tm /config /update
net stop w32time
net start w32time

Note the lack of space between manualpeerlist, the : and the ".

Domain configuration:

  1. Configure PDC emulator to sync to external time source [1]:

    w32tm /config /manualpeerlist:"pool.ntp.org time.nrc.ca" /reliable:yes /update
     
  2. If you move the role of the PDC emulator to a new domain controller, Change the Windows Time service configuration on the previous PDC emulator [2].

    w32tm /config /syncfromflags:domhier /reliable:no /update
    net stop w32time
    net start w32time
     
  3. Configure a client computer for automatic domain time synchronization [3]:

    w32tm /config /syncfromflags:domhier /update
    net stop w32time
    net start w32time

Further reading:
Windows Time Service Tools and Settings
http://technet.microsoft.com/en-us/library/cc773263(WS.10).aspx

Good overview - explains domain hierarchy and time architecture
http://blogs.msdn.com/w32time/archive/2007/09/04/keeping-the-domain-on-time.aspx

Configuring a time source for the forest
http://technet.microsoft.com/en-us/library/cc784800(WS.10).aspx

How to synchronize the time with the Windows Time service in Windows XP
http://support.microsoft.com/kb/307897

Sources:

[1] http://technet.microsoft.com/en-us/library/cc786897(WS.10).aspx via http://go.microsoft.com/fwlink/?LinkId=91969
[2] http://technet.microsoft.com/en-us/library/cc738042(WS.10).aspx  
[3] http://technet.microsoft.com/en-us/library/cc758905(WS.10).aspx via http://go.microsoft.com/fwlink/?LinkId=91376

Improving Exchange 2010 OWA Page Loadtimes

Summary:

Exchange 2010 has an updated OWA - now renamed Outlook Web App.  There are plenty of new features and improvements, but I've also noticed a dramatic increase in the page loadtimes, particularly on slower client connections.  Page loadtimes can be improved without any server-side code (JS/HTML) changes by ensuring that gzip compression is enabled end-to-end - which is, by default, not the case if OWA is published through Forefront TMG.  I reduced my OWA page loadtime from 27.47s down to 11.22s.

Problem:

Large pages of text can be compressed with gzip which dramatically improves loadtimes for most browsers.  By default, gzip compression may not be enabled in your Exchange 2010 IIS configuration, and may not pass through your Forefront TMG server publishing rule.  My Forefront TMG MBE was NOT configured to gzip .js and .css files, nor was it correctly configured to return compressed content (where appropriate) from published servers.

Solution:

  1. Load OWA in Firebug and note the current loadtimes.  In the screenshot below, the JS library loadtime constitutes a significant portion of the overall page loadtime.  If you are not seeing this, then the following steps are unlikely to improve your loadtimes.  Make sure you hit Ctrl+F5 to reload the page without a cache.
    See http://justinho.com/files/uploads/OWA-01.png .  Note the ClientStrings currently is 29.6kb and the uglobal.js file is 799.1kb, resulting in a page loadtime of 27.47s, a near eternity.
     
  2. Drill into the uglobal.js file in Firebug.  This step is to confirm that gzip compression is not enabled for the .JS file in question.
    See http://justinho.com/files/uploads/OWA-02.png .  Note the lack of the gzip compression in the Response headers.  gzip compression is not enabled when the client receives this JS file, but it is being requested (note the presence of gzip, deflate in the Request headers under Accept-Encoding.)
     
  3. Let's fix that.  Ensure the /owa directory has high compression enabled on your OWA/CAS server. (Depending on your exact TMG configuration, this may prove to be moot since TMG may decompress your CAS server's response only to compress it again before sending it over the WAN.  See [2] before proceeding with this step.)

    In an Exchange PowerShell on the CAS [3]:
    Set-OwaVirtualDirectory -identity "owa (Default Web Site)" -GzipLevel High

    Restart IIS services:
    iisreset /noforce
    (I personally got error messages when I did this, so you can also just run iisreset without the additional parameter, which will interrupt open sessions.  You are doing this change during a maintenance period, right?)
     
  4. Ensure Forefront TMG returns compressed HTTP content where possible.

    In Forefront TMG management, under Web Access Policy, find Configure HTTP Compression under Related Tasks on the right.  Ensure you Return Compressed Data from Anywhere (or at the very least, add your Exchange CAS servers):
    See http://justinho.com/files/uploads/OWA-06.png

    Note which filetypes are compressed as well:
    See http://justinho.com/files/uploads/OWA-07.png
     
  5. Ensure .CSS and .JS files are compressed.  By default, TMG compresses HTML Documents, and Text (as we saw in the previous step.)  This is fine since images don't compress well.  However, we want to ensure .css and .js files are also returned compressed.

    In Forefront TMG management, under Firewall Policy, click Toolbox on the right, then Content Types, and find HTML Documents.  Double click to edit and add the following types [4]:

    application/json
    application/x-javascript
    .css
    .js


    Screenshot: http://justinho.com/files/uploads/OWA-09.png.  Yes, I realise these are "applications" - but we really don't want to gzip .EXE and other files through this webserver - I just want to fix this particular JS and CSS slow page loadtime problem right now.
     
  6. Load OWA again now and note the reduced loadtimes in Firebug.

    See http://justinho.com/files/uploads/OWA-03.png .  The same ClientStrings request is now only 10.4kb, and uglobal.js is down to 202.7kb.  Page loadtime is now 11.22s, which is a dramatic improvement.

    Anyway, if we drill into the headers, we also see Content-Encoding shows gzip is now enabled in the server response:
    See http://justinho.com/files/uploads/OWA-04.png 
     
  7. Done.  This is still an eternity as far as I'm concerned, so I hope Microsoft gets this cleaned up in a future Service Pack for Exchange.  I suppose using a standard JS library that other people use would be too much to ask.  Perhaps this library can be hosted somewhere by Microsoft on a CDN, or at least the GUI should allow customers to host these JS files elsewhere on a secure CDN?

References:

[1] http://getfirebug.com/ or https://addons.mozilla.org/en-US/firefox/addon/1843

[2] If your TMG is decompressing then recompressing the CAS OWA response, you might as well disable compression on your CAS and let TMG do the work.  Regardless of what compression level you set on OWA on the CAS, the TMG always appears to use low gzip compression.  To find out what the TMG is doing, access your CAS directly on the LAN via https://internalIP/owa then access it when published by the TMG (i.e. https://mail.contoso.com/owa) and note any change in content size.  See step 1 above, ensuring you hit Ctrl+F5 to force a reload of the page.

If I load my OWA directly from the CAS, I see the effects of high gzip compression: http://justinho.com/files/uploads/OWA-05.png
If I load my OWA published through TMG, I see lower gzip compression (and thus larger file sizes): http://justinho.com/files/uploads/OWA-03.png

In this case (TMG publish filesizes > CAS OWA filesizes) gzip compression can likely be disabled on the CAS (or at least left at Low compression) to reduce unnecessary server load.

[3] http://technet.microsoft.com/en-us/library/aa996547.aspx

[4] These filetypes were determined by inspection via Firebug.  Ensure you load the Exchange Control Panel (/ecp) via the Options link, etc. to ensure you hit all file types.

Exchange 2010 Planning Resources

Microsoft Exchange Server Jetstress 2010 Beta (64 bit)
Simulate disk I/O load on a test server running Exchange to verify the performance and stability of your disk subsystem before putting your server into a production environment.
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=13267027-8120-48ed-931b-29eb0aa52aa6

Exchange Load Generator 2010 Beta (64 bit)
Exchange Load Generator is a simulation tool to measure the impact of MAPI, OWA, ActiveSync, IMAP, POP and SMTP clients on Exchange servers
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=cf464be7-7e52-48cd-b852-ccfc915b29ef

Microsoft Exchange Server Profile Analyzer (64 bit)
Collect estimated statistical information from a single mailbox store or across an Exchange Server organization.
http://www.microsoft.com/downloads/details.aspx?familyid=C009C049-9F4C-4519-A389-69C281B2ABDA&displaylang=en

You receive various Stop error messages in Windows 7 or in Windows Server 2008 R2 when you try to resume a computer that has a large SATA hard disk

You receive various Stop error messages in Windows 7 or in Windows Server 2008 R2 when you try to resume a computer that has a large SATA hard disk

  • You have a computer that is running Windows 7 or Windows Server 2008 R2.
  • The computer has a large Serial Advanced Technology Attachment (SATA) hard disk. For example, the size of the SATA hard disk is 1 terabyte.
  • You put your computer to sleep state or into hibernation.
  • You try to resume the computer from sleep or from hibernation.

Error messages:

STOP 0x0000007A
STOP 0x00000077
STOP 0x000000F4

Hotfix: http://support.microsoft.com/kb/977178/
Intel SATA driver update: http://www.intel.com/support/chipsets/imsm/

Tyan's AMI MegaRAC Port Usage

Summary:

Some of Tyan's server boards have IPMI and integrated iKVM functionality.  Securing access to these resources requires knowledge of specific TCP/UDP port traffic requirements.

The following ports are necessary:

  • Web: TCP 80, TCP 443
  • SSH: TCP 22
  • IPMI: TCP/UDP 623
  • KVM: TCP 7578, TCP 7582
  • Virtual Media: TCP 5120, 5123, 5124, 5127

Discussion:

I have an S7012 board with iKVM functionality that I was trying to expose over VPN.  My TMG VPN configuration has port access restricted to the DMZ - so I had to open specific ports to give myself access to the iKVM.  Took a while to find.  Board manual, AST2050 IPMI manual.

Source:

http://www.tyan.com/manuals/S7016_Pilot%202_UG_v100.pdf, page 34

How fast is a 2.4GHz 802.11n network?

With 802.11n routers and notebooks (and some desktops) appearing everywhere, I wanted to know how much faster an 802.11n 2.4GHz network would be, when it is running alongside other 802.11g networks.  Would I be able to set up an 802.11n network and have it serve just my media centre, for example, for video streaming, while leaving my 802.11g clients undisturbed?

So I did some (non-scientific) speed tests on a Linksys WRT160Nv3 (dd-wrt.v24-13309_NEWD-2_K2.6_mini_wrt160nv3), when it was running alongside a WRT54GS (tomato 1.25) router.  The WRT160Nv3 was configured with 40MHz (upper) channels to maximize speed, with the WRT54GS was on channel 10 to avoid overlap as much as possible.

I tested 3 different cases:

Configuration 1: Intel 5300 copying files over WRT160Nv3 (40 MHz upper)
Configuration 2: Intel 3945ABG copying files over WRT54GS (ch10, mixed bg mode)
Configuration 3: Intel 5300 copying files over WRT160Nv3 (40 MHz upper) while Intel 3945ABG copies files over WRT54GS (ch10, mixed bg mode)

That is to say, I wanted to collect some data on how this 802.11n network might co-exist with an 802.11g network in the 2.4GHz spectrum, and what the impact would be on performance.

Configuration 1: Intel 5300 copying files over WRT160Nv3 (40 MHz upper)
Elapsed time     1 min 22.0 sec
                                             Incoming         Outgoing
------------------------------------ ---------------- ----------------
Total of data transferred                    363.1 MB           7.4 MB
Maximum transfer rate                        6.1 MB/s       127.7 KB/s
Average transfer rate                        4.4 MB/s        92.0 KB/s

Configuration 2: Intel 3945ABG copying files over WRT54GS (ch10, mixed bg mode)
Elapsed time     1 min 22.2 sec
                                             Incoming         Outgoing
------------------------------------ ---------------- ----------------
Total of data transferred                    191.0 MB           3.8 MB
Maximum transfer rate                        2.6 MB/s        52.8 KB/s
Average transfer rate                        2.3 MB/s        47.7 KB/s


Configuration 3: Intel 5300 copying files over WRT160Nv3 (40 MHz upper) while Intel 3945ABG copies files over WRT54GS (ch10, mixed bg mode)

Intel 5300 / WRT160Nv3 simultaneous (ch5-2.432 40MHz upper)
Elapsed time     1 min 58.1 sec
                                             Incoming         Outgoing
------------------------------------ ---------------- ----------------
Total of data transferred                    532.8 MB          11.1 MB
Maximum transfer rate                        6.7 MB/s       142.2 KB/s
Average transfer rate                        4.5 MB/s        96.2 KB/s
 
Intel 3945ABG / WRT54GS CGN1 simultaneous (ch10-2.457 mixed bg)
Elapsed time     1 min 55.9 sec
                                             Incoming         Outgoing
------------------------------------ ---------------- ----------------
Total of data transferred                     49.6 MB           1.2 MB
Maximum transfer rate                        1.4 MB/s        33.7 KB/s
Average transfer rate                      438.4 KB/s        10.3 KB/s

Conclusion:

Even on 2.4GHz, 802.11n with 40MHz channel width is roughly double the speed of an 802.11g network.  But when an N network is put next to a G network in the 2.4GHz space, the G clients lose 75% or more of the performance on the average case, while N clients are virtually unaffected; your N clients will run at full speed, and G clients can barely surf the web.

Anecdotally: I'm seeing similar performance degradation when an 802.11g client is connected to an 802.11n 2.4GHz AP.  The 802.11n clients run fast when it's a pure 802.11n network.  But as soon as some 802.11g clients show up, compatibility mode kicks in, and the 802.11g clients only get around 500-700kb/s, which is still at least a 50% performance hit, and the 802.11n clients lose around 20% of the speed.  (Yes, this paragraph is completely unsubstantiated.  That's why it starts with "anecdotally"...)

Recommendation:

Based on my (extremely) unscientific tests, I'd say that if you really want a faster wireless connection, keep your 802.11bg clients on your G access point, and get a 5GHz 802.11n access point for your faster N clients.  Mixing clients on an AP seems to ruin things for everyone involved.  Even putting a separate 802.11n 2.4GHz AP next to your 802.11g network doesn't help the 802.11g clients.

Or, just replace all your clients with 802.11n cards, and run a 2.4GHz 802.11n network for a nice doubling of network throughput.

Resolving Xerox 6180MFP - Error code 033-762 Fax not recieving

Symptoms:
Xerox 6180MFP refuses to accept inbound faxes - giving error code 033-762.

Solution:
Disable the Junk Fax Filter Feature

Make Sure the Machine is Properly Configured to Receive Faxes

Solutions for Unable to Receive Faxes

Note:
When the Junk Fax Filter feature is enabled, the printer will only print faxes that are received from telephone numbers that have been registered in the printer’s Address Book. If a Fax Communication Error is received with a fault code such as 033-762 and the Junk Fax Filter feature is enabled, make sure the fax being received is sent by a telephone number registered in the printer's Address Book. If the number has not been registered in the Address Book, disable the Junk Fax Filter feature to allow reception of the fax.

Benchmarking SSD Performance

I've recently been using a few SSDs - so I thought I'd put together some resources that I found useful.

I'll try to keep updating this post with more information as I go.

 Drive information:

  • G.Skill Falcon II 64GB - FM-25S2I-64GBF2
  • <coming soon>