Countdown to TechEd 2010 in New Orleans, LA: 2010-06-07 00:00:00 GMT-08:00

Sunday, January 31, 2010

Change is Good

Very soon I plan to make some changes to the EXPTA {blog} (hopefully for the better). 

I'll be moving this blog from my own hosted server to "the cloud," hosted by Google, to increase response time.  I'll also make some rather dramatic changes to the blog's layout.

I started this blog primarily for myself, as a form of "long term memory."  I come across so many gotchas and things that are good to know in my line of work that I sometimes can't remember all the details.  It helps to document them and keep them in a place where I can access them anywhere anytime.  As time went on, I found that a lot of other IT pros were looking for the same information I was.  So rather than just jot down little notes to myself, I decided to fully document my findings here to help others.  At the time of this writing, I've had over 400,000 visitors (thanks, Mom!), so I seem to be doing something right.

Since I started this blog in April 2007, screen resolutions have changed and widescreen displays are more prevelant.  To that end, I've been tweaking a fluid template that automatically adjusts to your screen resolution.  Hopefully, you'll find this layout easier to read than the single thin column of the current blog layout.  Look for it in the next day or so.



Subscribe in a reader Subscribe by Email

Wednesday, December 30, 2009

Really, Really Good Advice

Sriram Krishnan works on the Windows Azure team at Microsoft. He recently published a post, Stuff I've learned at Microsoft, which gives great advice and commentary on things he learned in his five+ years at Microsoft.

I highly recommend taking a few minutes to read it.

Labels: ,

Subscribe in a reader Subscribe by Email

Thursday, September 10, 2009

Worst. AT&T Experience. Ever.

The EXPTA {blog} is back online!  Sorry about the prolonged outage, folks.

This blog is hosted on my own server, which is connected to the Internet using a DSL line from AT&T.  I choose to do this instead of hosting it on blogspot because it gives me a lot more flexibility.

I finally decided to cancel my local phone service, since we only use our cell phones anyway, and why pay $25 a month to let cold-callers interrupt our dinner.  Trouble is, a provisioned DSL line is normally tied to the landline phone number.  To get DSL on its own, it needs to be converted to what AT&T calls a "dry loop".  This can be done very quickly at the central office (CO), and then the phone line can be disconnected.  When done correctly, the outage is very brief and the DSL customer (me) retains his user accounts, email addresses, and settings.  But, when it's done wrong....

Problem #1: Human nature. When making a change request such as this (disconnect local phone service), the AT&T rep taking the call is a salesperson.  Salespeople don't make money disconnecting service.  Salesperson: "How can I make a buck off this? Ahh, I'll cancel BOTH the local phone service and DSL, and then put in a NEW order for DSL.  Cha-ching!"  Oh, and don't bother telling the customer (me) that you're going to do this.

Problem #2: Phone mail hell. The work will be performed sometime between 8am-8pm.  My DSL was turned off promptly at 8am (of course), but my phone still worked.  Several calls throughout the day resulted in transfers to at least three different departments. Apparently none of them work for the same company. "Be patient, sir, your order will be completed by 8pm."

Problem #3: We're closed. At 8pm sharp, my phone service stops, but I still don't have DSL.  I called the "broadband customer care" department and find that all the techs have gone home for the day.  A supervisor says he'll put me "first on the list tomorrow morning at 8am and we'll call your cell".  Guess what?

Problem #4: Wires crossed. Many phone calls (all by me) and a service tech visit to the house (how could it possibly be a problem with my house wiring when it was working before they started screwing around?) results in a trip to the central office.  "Oops, we connected the wrong wires."

So, 34 hours later I finally have my DSL service back, albeit with a new account and no access to my old email accounts.  Next stop, a call to the Customer Retention department for a bill credit.  Grrrrr!

Labels: ,

Subscribe in a reader Subscribe by Email

Monday, February 25, 2008

Ease up on Silverlight already!

It seems you can't use any Microsoft website anymore without being nagged to install Silverlight.

While I love "the next generation of media experiences and rich interactive applications for the Web" as much as the next guy, I don't know what value it's going to bring to sites like TechNet, MSDN, etc. My chief complaint is the slow performance of Silverlight on RDP sessions. Most administrators perform their work using RDP and the abysmal performance of Silverlight enabled websites (or any website that uses transition effects) prevents administrators from getting their job done.

It might be nice if there were an option in the RDP client to allow Silverlight, just like there is one to allow menu and window animation. Just thinking out loud here...

Labels: ,

Subscribe in a reader Subscribe by Email

Tuesday, February 12, 2008

New File Extensions Blocked in Outlook 2003 SP3

After several months of testing, a client recently deployed Service Pack 3 for Microsoft Office 2003 to nearly 10,000 clients via WSUS. They have a scripted routine that they follow during testing of patches and updates to ensure that there are no interoperability issues, but of course, you can't test everything. I mean, how are you going to know that a certain update will prevent an HP 4200 printer from feeding from the secondary paper tray? And yes, I've actually seen that happen.

Well, shortly after deployment they start getting complaints that emails with links to Public Folders (XNK files) can't be opened on Outlook 2003. Could it be that Microsoft actually did this on purpose? After an hour or so of re-reading all the scattered documentation for Office SP3, including Information about certain file types that are blocked after you install Office 2003 Service Pack 3 and the Downloadable list of issues that the service pack fixes, I couldn't find anything that documented this change.

I opened a case with Microsoft and found that not only are XNK extenstions blocked, but several others are as well. Here's an unofficial list of the extensions blocked by Outlook 2003 SP3 (I apologize for all the blank space that Blogger inserts before this table, please scroll down):

File ExtensionFile Type

Access Project Extension (Microsoft)

.adpAccess Project (Microsoft)
.appExecutable Application
.aspActive Server Page
.basBASIC Source Code
.batBatch Processing
.cerInternet Security Certificate File
.chmCompiled HTML Help
.cmdDOS CP/M Command File, Command File for Windows NT
.cplWindows Control Panel Extension (Microsoft)
.crtCertificate File
.cshcsh Script
.derDER Encoded X509 Certificate File
.exeExecutable File
.fxpFoxPro Compiled Source (Microsoft)
.gadgetWindows Vista gadget
.hlpWindows Help File
.htaHypertext Application
.infInformation or Setup File
.insIIS Internet Communications Settings (Microsoft)
.ispIIS Internet Service Provider Settings (Microsoft)
.itsInternet Document Set, Internet Translation
.jsJavaScript Source Code
.jseJScript Encoded Script File
.kshUNIX Shell Script
.lnkWindows Shortcut File
.madAccess Module Shortcut (Microsoft)
.mafAccess (Microsoft)
.magAccess Diagram Shortcut (Microsoft)
.mamAccess Macro Shortcut (Microsoft)
.maqAccess Query Shortcut (Microsoft)
.marAccess Report Shortcut (Microsoft)
.masAccess Stored Procedures (Microsoft)
.matAccess Table Shortcut (Microsoft)
.mauMedia Attachment Unit
.mavAccess View Shortcut (Microsoft)
.mawAccess Data Access Page (Microsoft)
.mdaAccess Add-in (Microsoft), MDA Access 2 Workgroup (Microsoft)
.mdbAccess Application (Microsoft), MDB Access Database (Microsoft)
.mdeAccess MDE Database File (Microsoft)
.mdtAccess Add-in Data (Microsoft)
.mdwAccess Workgroup Information (Microsoft)
.mdzAccess Wizard Template (Microsoft)
.mscMicrosoft Management Console Snap-in Control File (Microsoft)
.mshMicrosoft Shell
.msh1Microsoft Shell
.msh2Microsoft Shell
.mshxmlMicrosoft Shell
.msh1xmlMicrosoft Shell
.msh2xmlMicrosoft Shell
.msiWindows Installer File (Microsoft)
.mspWindows Installer Update
.mstWindows SDK Setup Transform Script
.opsOffice Profile Settings File
.pcdVisual Test (Microsoft)
.pifWindows Program Information File (Microsoft)
.plgDeveloper Studio Build Log
.prfWindows System File
.prgProgram File
.pstMS Exchange Address Book File, Outlook Personal Folder File (Microsoft)
.regRegistration Information/Key for W95/98, Registry Data File
.scfWindows Explorer Command
.scrWindows Screen Saver
.sctWindows Script Component, Foxpro Screen (Microsoft)
.shbWindows Shortcut into a Document
.shsShell Scrap Object File
.ps1Windows PowerShell
.ps1xmlWindows PowerShell
.ps2Windows PowerShell
.ps2xmlWindows PowerShell
.psc1Windows PowerShell
.psc2Windows PowerShell
.tmpTemporary File/Folder
.urlInternet Location
.vbVBScript File or Any VisualBasic Source
.vbeVBScript Encoded Script File
.vbsVBScript Script File, Visual Basic for Applications Script
.vsmacrosVisual Studio .NET Binary-based Macro Project (Microsoft)
.vswVisio Workspace File (Microsoft)
.wsWindows Script File
.wscWindows Script Component
.wsfWindows Script File
.wshWindows Script Host Settings File
.xnkExchange Public Folder Shortcut

Nothing p$%#es me off more than undocumented changes in functionality. At this point in time, this information is not documented ANYWHERE on Microsoft's website.

I certainly don't mind Microsoft fixing security holes, but for crying out loud, DOCUMENT IT!!! How do they expect us to roll out critical patches and updates if they change functionality and don't tell anyone? No one looks good when that happens.

Labels: , , ,

Subscribe in a reader Subscribe by Email

Thursday, June 28, 2007

Beware the iPhone

The iPhone is a (very) expensive consumer device that has no place in the corporate environment. It has no security, cannot connect to enterprise email systems except using unsecured protocols (IMAP), and opens the company up to potential (extremely likely) copyright concerns.

Most companies should have a corporate "Just say no" policy for the iPhone in place by now. That way when the CEO drops his new iPhone on the administrator's desk and says, "Make it work with my email", they'll have a response ready.

On a side note, surveys have shown that people are really interested in three things about cell phones: Service quality (they want to be able to place or answer a call, not be dropped and be heard clearly), battery life, and ease of use (not having to use arcane menuing systems). Everything else is just gravy. When you add email to the mix, people want to be able to easily send and receive emails (tiny keypads and menuing systems inhibit this) and to a smaller degree expect fast delivery.

It seems that cell phone companies are busily trying to create "the next big thing" by adding the last big thing to their already crowded and confusing devices. Most people don't use 1/4 of the features on the phones they already have.

Labels: , , ,

Subscribe in a reader Subscribe by Email