I did enjoy this little Marketing message from Microsoft, basically saying please come and buy Windows 8.
Marketing aside, April 8th 2014 has been and gone and much like the Y2K bug we are all still here. Some might say for how long, especially in light of patch of the first patch Tuesday looming tomorrow. Time will tell but no matter the threat there will be thousands of businesses who will still be on XP for years to come.
I feel I can say that with a degree of confidence as I still see the odd NT 4.0 box kicking around, maybe in the next year or so the bulk of companies will have moved off of XP but the question that interests me is what will people move too? I don’t intend on answering that, it’s a question that is as long as it is broad, but it’s just the Operating system and does the business even care if its Windows 7 or Windows 8.1. They just want something that works and is secure. At least that is the push back that I get from my board.
If you look at how EUC is evolving and think back to what XP did during its life time I think we will not see such a dominant Desktop OS in the enterprise again. Users are demanding more flexible means and ways of working and that takes the focus away from the OS and places its squarely on the applications and how they are delivered.
I started in IT during 1999 so I saw the big change over from NT to XP and I am pretty sure that the cycle is just repeating itself with XP and Windows 8 for example. We IT folk just don’t like change, when in actual fact we should relish it. Whilst I look back with a great fondness for XP, I for one am really pleased to be moving on as these days it just does not cut it and I grow tired of trying to make it bend to life in 2014, most of our service desk tickets are related to XP and how it doesn’t quite support this or it wont do that.
In closing I bid a fond farewell to XP and I am saying hello to post XP support (yes, I can’t quite get rid of it all yet!) as well as planning for the demise of Windows Server 2003! The clock is already ticking folks….
Today I had to dust off the Exchange troubleshooting hat and look at a mail flow issue.
We have one Exchange 2003 server that holds our public folders and a legacy send connector that we cannot seem to migrate to our 2007 HT server. A number of users had called saying that reports and sending mail to public folders were failing.
I quickly tested the internal & external mail and all appeared ok <phew> so it was localised to the 2003 server. I did the basic checks, services started, can I telnet to SMTP port, checked the event logs and the queues. All was looking good except the queues which had around 4000 messages sat in the “Messages with an unreachable destination queue” Looking at the mail addresses
Doing a find messages showed that the first message was just after mid-night on the bank holiday Monday. You cannot force messages to retry from this queue, you can just freeze and unfreeze and delete choosing of to send an NDR.
So I decided that a quick way to get the messages to retry would be to stop and start the SMTP server. Sure enough the queue was flushed and I saw them retrying. This was the first clue. As I saw then hit the routing group connector (RGC) to my 2007 hub transport server and that’s where they stayed for a while before moving to the unreachable destination queue.
So, off to the Hub Transport server. A quick look over the event logs showed an error that occurred about 1 minute before the first mail was submitted and got stuck. The picture below shows the event log message.
I checked the Message Transport service and lone behold it was stopped, a simple restart was all that was required. But what of the mails, they were still stuck.
I restarted the SMTP virtual server again and the mails slowly started to send but not all of them went. About half way through it all stopped. Further checking I found that taking one of the mails out of the queue and then re-sending stopped the service from crashing.
So it would appear that a corrupt mail was the cause. I did do some R&D on that error just to be sure and a lot of people were complaining of corrupt que files and rebuild the MT databases. I will keep an eye on things and update this post should it fail again.
Every now and then you find these little commands that you never knew existed.
Today I just wanted to know when a users password was expiring, but I didn’t have access to my AD Users and Computers with the additional account info tab.
So, I found this little gem..
net user <username> /domain
You get some additional info but it will list when the user account password expires.
Example: net user johnsmith /domain
In case you didn’t know you can download the 2003 server resource kit and register the acctinfo.dll. To remove this tab you just unregister the file. See the examples below..
Before running these commands you will have to copy the DLL to the system32 folder. I only suggest doing that as it seems like a logical place to put it. If you dont agree then just register it in the default location of
“C:\Program Files\Windows Resource Kits 2003\Tools”
To register: regsvr32 %systemroot%\system32\acctinfo.dll
To unregister: regsvr32 /u %systemroot%\system32\acctinfo.dll
EDIT – Just a thought, I have done this Acctinfo on my workstation, I am not a fan of putting these add-ons on a server if it’s not required. You also have to place this DLL on all machines that you wish to see the additional tab from.
I thought that this was worth a blog post as a number of people have poted on the VMware forum with no real answers being mentioned.
The other day I had done a P2V on a Windows 2003 SP2 SQL server. All was going well until I had to put the LUNS back. I masked them on the netapp to the ESX hosts in the cluster and removed the physical server. I then performed the usual rescan and refresh in ESX, all was going well as my new LUNS were listed.
I then added the LUNS to the VM as a Raw Device Map. Again this all went well. However after doing a rescan and refresh in disk manager nothing appeared. I tried a diskpart rescan and list disk but alas no disk.
Here are some of the things that I looked at.
- Stopping services
- Cleared and monitored the event logs for errors
- Made sure that all previous SAN and Multi Path software was removed
- Checked ESXi pathing and masking was correct
- Deleted the RDM mapping files and readded them
- Removed old devices from device manager that were left behind
It was worth noting though that the LUNS were listed in device manager as being connected to the LSI SCSI controller.
In the end I had run out of time in my window so I had to roll back to the physical server but thats another story. However I left the VM disconnected from the network so I could spend more time fixing it.
So a fresh pair of eyes helped me to fix the issue. First I tried removing the disk mapping files by doing a delete from disk and then rea dding them. This made no odds. So I tried again but instead of choosing a Physical RDM I chose virtual. This was not ideal as I really didnt want any VM admin to be able to snap the LUN being it was a database. However by using virtual I could see the disk in Disk manager. I then removed it and tried a pRDM again but alas it was in device manager but not disk manager.
So I then decided to add the pRDM again but this time using a SCSI ID that created a new controller and guess what.. It worked! whilst I dont quite understand why this is the case it did not cause me any issues to have another controller.
I hope that this may help someone else solve their issue.