.comment-link {margin-left:.6em;}
A Collection of Random Thoughts
Monday, October 31, 2005
 
SysInternals uncovers Sony DRM Rootkit
That doesn't sound good...did I read that right?  A Rootkit?  Don't you usually associate Rootkits with hackers and malware attempting to cover their tracks?  Don't know about you, but I sure do.
 
Mark Russinovich of SysInternals recently found that Sony's DRM protection scheme employs a rootkit in order to hide itself.  Read his blog here.  Not only that, but it places hooks deep into the OS that make it near impossible for anyone but the most advanced users to get rid of it afterwards.  How did this rootkit get installed?  Simply by playing a CD that had protected content on it on his computer.
 
First off, I'm not a fan of DRM to begin with.  If I purchase something (song, cd, whatever), no one should be telling me what I can and can't do with that, or what devices I can and can't play it on.  Secondly, for a large music corporation like Sony to resort to something like this is absolutely pitiful.  It makes me lose any and all respect for them.  It also stinks of a lawsuit.  It will be interesting to see how this pans out. I'm betting that they (Sony) didn't count on anyone finding this out.
 
Make sure to read Mark's blog to get entire coverage of how he went about discovering what Sony did and how he finally got rid of it.

- posted by Ben Winzenz @ 4:25 PM 0 comments
Tuesday, October 25, 2005
 
Exchange 2003 SP2 confusion
I've seen quite a bit of confusion about SP2 and the requirements.  Most of it centers around IMF and what to do if you have IMF v1 installed (SP2 containst IMF v2), and what to do if you want to enable the Sender ID checking filter.
 
I personally believe that these questions can be answered by simply reading the Relase Notes.  They quite clearly state the following related to SenderID:
 
Important:
Before you enable Sender ID on Exchange 2003 SP2 server, make sure that you apply the Windows Server 2003 hotfix that is referenced in Microsoft Knowledge Base article, "Windows Server 2003 may stop responding when you enable Sender ID filtering on an SMTP virtual server in Exchange Server 2003 SP2." Windows 2000 Server is in extended support mode only. Please contact your Microsoft account representative for information about obtaining the hotfix for Windows 2000 Server. For more information about this issue in Windows 2000 Server, see the Microsoft Knowledge Base article, "Windows 2000 Server may stop responding when you enable the "Sender ID Filtering" setting on an SMTP virtual server in Exchange Server 2003 SP2."
 
Of course, for now, this means that you have to call PSS to get the hotfix, but hotfix calls are free.  In fact, there is even an option on the phone menu to press if you are calling for a Hotfix.  you get routed to a Customer Support representative and give them the KB article and they send you the hotfix.
 
Regarding IMF, they also clearly state that IF you have IMF v1 installed, it must first be uninstalled prior to installing SP2.  Though it is clear about what must be done during the install, what isn't clear is how to re-enable IMF once you have remove v1 and installed v2 with SP2.  Bharat Suneja has a post in his blog that details how to re-enable IMF over here
 
Other standard rules apply, such as upgrading Front End servers prior to upgrading Back End servers.
 
It is also recommended to be running Windows 2003 SP1 on your Exchange 2003 server, as this is required to enable SMTP Tarpitting.
 
The Release Notes for SP2 can be found here.  If you are planning on installing SP2, I'd highly recommend to read through them.  They contain a lot of useful information, and are only a few pages long.  It shouldn't take more than about 5 minutes to read through them.

- posted by Ben Winzenz @ 5:06 PM 0 comments
Thursday, October 20, 2005
 
Good press for AMD from HP
I originally read about this over here and the original story can be found here
 
This really is huge news from HP.  It comes from HP's Technology Forum and basically several different managers at HP state that the performance of AMD's Server class processor, the Opteron, is better than Intel's Xeon processors.  When you get into 64-bit and dual-core, AMD outpaces Intel even more, according to HP.
 
I've always been a big fan of AMD.  You gotta love them - they are the perpetual underdog in this (their market share is much lower than Intel), yet their products continue to be high quality time and time again.  With HP being one of the only major vendors that sells both AMD and Intel chips in it's server lines (along with Desktop and Laptops), this sort of comes as a surprise.  It just isn't common to see comments like this.  It's not that I don't agree - I wholeheartedly DO agree with the comments.  Benchmarks of the two processors always seem to come out in favor of AMD.  Personally, I have used AMD processors for a long time.  When I get another PC, it will likely be the AMD dual core desktop chip.
 
As a co-worker said to me, AMD is the best thing that could happen to Intel, because it forced them to compete (and innovate).  More competition equals better products, which is better for us as consumers.

- posted by Ben Winzenz @ 12:15 PM 0 comments
Friday, October 14, 2005
 
Outlook AutoComplete and LegacyExchangeDN
Recently, I've seen several posts referring to Outlook's autocomplete feature (Automatic Name Resolution) displaying incorrect information.  Specifically, this information was stored in the legacyExchangeDN value assigned to a user account.  OK, I'll correct the legacyExchangeDN value, you say.
 
Before you do that, however, be aware of the unintended consequences of doing such.  Outlook actually still uses the legacyExchangeDN value for some things.  For one, it uses the legacyExchangeDN when replying to messages sent by an internal user.  You don't believe me?  Well, it is sort of hard to find, but try this.
 
Download the MDB Viewer utility (MDBVu32) from Microsoft and open your mailbox and view a message that was sent by an internal user.  Specifically, look at the PR_SENDER_EMAIL_ADDRESS property.  Guess what that is :-)  Yep - that's the legacyExchangeDN value on an account.  Still don't believe me?  Use ADSIEdit and go to the properties of the user account in question.  Go down and view the legacyExchangeDN.  You should see that it will match the PR_SENDER_EMAIL_ADDRESS property.  Now, if you modify the legacyExchangeDN value for a user account, the message still has the OLD value listed - that doesn't get modified.  So, when Outlook tries to reply to the message, it tells Exchange to send to the account with the OLD value, which no longer exists.  Since that value no longer exists, an NDR will be generated.  Not fun.
 
How do you get around this?  There are 3 things that I can think of.
 
1.  Don't rename/re-use user accounts.  If you want the new account to be a member of the same groups as the old one, then simply Copy the account.  At one point at a previous employer, we created "dummy" accounts that were only there so they could be copied.  If you make a practice of creating a new account for each new user, you won't have to deal with incorrect legacyExchangeDN values.
 
2.  Disable Outlook's Automatic Name Resolution feature.  Ok, this may not be the most viable option, but by disabling ANR, you don't have to deal with Outlook caching and displaying incorrect information in it's autocomplete names.  This will allow you to leave the legacyExchangeDN value intact and not worry about
 
3.  If you MUST change the legacyExchangeDN value, make sure that you add the OLD legacyExchangeDN value as an X500 address on the user account.  This will allow replies to still work because the address Outlook tells Exchange to use is still valid.
 
Ben

- posted by Ben Winzenz @ 10:36 AM 2 comments
Saturday, October 08, 2005
 
Great new Exchange news!
Exchange 2003 clusters will now support Standby clusters!  What does that mean?  It means that you can now recover a production Exchange virtual server to a totally different cluster.  This is great news if the number of users your servers support dictate a cluster. 
 
Evan Dodds pointed this out in his blog
 
Information regarding hardware requirements and instructions on how to configure the standby cluster can be found at:
http://www.microsoft.com/technet/prodtechnol/exchange/guides/DROpsGuide/2493c2d6-618c-4c49-9cb1-fff556926707.mspx
 
Instructions are included on how to move the production virtual servers to the standby cluster as well as how to move the virtual servers from the standby cluster back to the production cluster once it has been rebuilt/repaired.  One recommendation worth noting here is that the IP address of the standby cluster is recommended to be in the same IP subnet as the production cluster.  This is due to potential latency issues within Active Directory, WINS and DNS replication and client name caches, and can potentially cause the cluster resources to go offline.  Obviously, if your entire production cluster is offline, then there wouldn't be much choice here, but this is one thing to take into consideration if you will be employing a Standby cluster as a disaster recovery plan.
 
Ben Winzenz, MCSE
MS Exchange MVP
Senior Support Engineer
MessageOne
Austin, TX
(512) 652-4500
 

- posted by Ben Winzenz @ 1:30 PM 0 comments

Powered by Blogger