UM Kit offer from the Exchange team
Are you part of the Exchange 2007 Beta, but haven't deployed the Unified Messaging bit because you don't have a VOIP gateway that you can integrate it with? Have no fear. Thanks to the effors of the folks on the Exchange team, for a limited time you can purchase a trial kit for $1000 that includes not only an analog IP Gateway, it also includes a full 2 hours of support to help get it set up and working with Exchange 2007.
One thing to note - the actual hardware costs far less than $1000. You can pick up the same piece of hardware (Audiocodes MediaPack 114 FXO) for ~$450, which means that the phone consultation bit is rather expensive. If you haven't had any experience with VOIP or setting up a VOIP gateway, this still might be a good deal, but if you have experience, I'd recommend just getting the hardware yourself and setting it up. The Exchange help file (and online documentation) is very good when it comes to information about UM. There are lots of places where you can get the VOIP gateway (note that currently, there are only 2 such gateways that are supported as being compatible for testing). Here are some links where you can get the VOIP gateway.
Office 2007 Beta2 Tech Refresh is out
Which gaming console is the best?
There are lots of varying opinions out there, and each manufacturer states their console is the best (ok, with probably the exception of Nintendo, whom I haven't heard a lot of "smack" from).
The obvious players in the gaming console are the following:
Microsoft Xbox 360
let's do a quick comparison of the 3 and some of their basic features.
$299 Core/$399 Premium
Standard DVD-Rom/HD-DVD optional accessory
Blu-Ray DVD Standard
Standard DVD player
At first glance, the PS3 wins out in the features category, but does it justify the $200 premium over the 360, and even more over the Wii? That's for you to decide.
Also, note that I left out the processor/video specs. While there is much hype about the Cell processor in the PS3, I have to date seen nothing that indicates it will soundly trounce everything out there. In fact, it seems like each time there is an update, revised specs are released that show lower capabilities.
As far as availability, the XBox360 has the obvious advantage here. It's already been out for a year, and will have the most games available.
All 3 systems claim to be backwards-compatible with previous games, though the XBox 360 requires the hard drive (or a memory module) in order work with Xbox games, as they store information on the hard drive on the original XBox.
Nintendo clearly has the most innovative design for their controller, but it really remains to be seen if it will be accepted or not. Sony and Microsoft have stayed the conventional route with their controllers.
All 3 systems will be touting online gaming capability, but I'd give the edge to the 360 here as well. XBox Live is a well-established service, and has been around for several years. There is a subscription cost, but at ~$50/year, it's a relative bargain. Last I'd heard, the online gaming from both Sony and Nintendo will be free, but I don't think they really have much choice here. In order to get an online gaming forum up and running, you can't really start charging at the onset, or you won't get near as many people to join.
So - which one would I buy? I certainly won't put out $500 or $600 for the PS3. I paid $150 for my original XBox, and I'm not willing to quadruple the cost of that to satisfy my gaming craves. That leaves the Xbox 360 and the Wii. The 360 has been out longer, and is likely to drop in price sooner (at least I think it will), and since I've already got an XBox, my likely choice will be the 360, though I won't be rushing out tomorrow to get one. Which console others will choose may depend on the current gaming console they own. If you have a PS2, my guess is that you'd be more likely to get a PS3 and be able to play all games from it instead of having 2 separate consoles. However, Sony is going to have a distribution problem with the PS3. The launch date here in the US (and in Japan) is supposed to be mid-November, but reports I've heard indicate they are going to have limited numbers of units available for the US and Japan (Europe's launch date has even been postponed until Spring of 2007). This means the mark-up by retailers could be quite a bit.
Time will tell how this next generation of gaming console wars turns out.
550 relaying denied for local domains
Have you ever experienced your Exchange server suddenly (or not) rejecting all messages destined for local domains (i.e. the ones listed in your recipient policies)? Here are a couple of things you can check to see what is going on.
First, manually telnet to your Exchange server on port 25, and attempt to send a message. I won't go through all of the commands, but the Rcpt to: command is the most important here. If you are seeing this problem, as soon as you enter the rcpt to: command and enter the e-mail address of a user in that domain, you will see the 550 relaying denied message. A little trick here is that with Exchange 2000 and 2003, you can actually get away with just typing the username. For example, instead of typing
rcpt to: email@example.com
you would type
rcpt to: user
When you do this, Exchange 2000 and 2003 will automatically append the smtp domain information and convert it to firstname.lastname@example.org. In this case, performing this action resulted in Exchange returning email@example.com, which was not a part of recipient policies.
This gave me a clue as to what the problem might be, and leads to the next part.
Open Internet Information Services Manager, and expand your server name and check for the existance of an SMTP Virtual server in there. See, when you install Exchange, it requires SMTP to be installed, but during the installation, it takes over ownership (and managing) of the SMTP bit. In other words, SMTP should not show up in IIS Manager. If it does, then you know that Exchange isn't managing SMTP as it should. Fortunately, the solution to this problem is fairly easy.
If you have uninstalled/reinstalled IIS, then you have to reinstall Exchange. This is done simply by re-running Exchange setup and choosing Reinstall from the drop-down box for the install options. Don't worry - this doesn't touch the databases, it just reinstalls the Exchange binaries (\Exchsrvr\bin). Upon completion of this step, you would then need to reinstall any Exchange service packs and hotfixes.
If you have only uninstalled/reinstalled the SMTP component, then it's even easier. By following the instructions in http://support.microsoft.com/kb/290290/EN-US/, you can run smtpreinstall.exe and fix the relationship between Exchange and SMTP.
As also mentioned in the article, the other clue that will guide you to this conclusion is if there are missing SMTP verbs. When you type the EHLO command into your telnet session, all of the supported SMTP verbs will be listed.
If you don't see the following, then the Exchange verbs are not present, and you need to follow the above instructions to repair it.
250-X-EXPS GSSAPI NTLM LOGIN
250-AUTH GSSAPI NTLM LOGIN
Fixing Suspect SQL databases
Disclaimer: This probably should not be done on a production system! I have several SQL servers for use by our Developers, and none of them have any critical data on them. If you have a database that has been marked suspect by SQL, the best course of action that I am aware of is always to restore your data from backup.
I used the instructions provided byPaul Randal, who is a Lead Program Manager for SQL, at http://blogs.msdn.com/sqlserverstorageengine/archive/2006/06/06/619304.aspx
In my case, the problem database was the msdb database. With this db marked as suspect, the SQL Agent service would not start. Checking the SQL Agent log indicated this was the reason. As Paul mentions, since msdb is a system database, you can't repair it like you would others. In order to fix this problem, I had to start SQL by using:
start sqlservr.exe -c -T3608
This starts up SQL in a special mode where it only attaches to the master database. You can then run the instmsdb sql script to reinstall the msdb database. Running this script will first detach, then remove the msdb database files, then re-create and re-populate them. The proceure for doing this is quite simple. From the \sql\install directory, run the following command.
osql -E -S servername -i instmsdb.sql
Note: when you start SQL with this flag, the SQL service itself does not appear started. Instead, a separate cmd window will pop up with the SQL information. When you are ready to exit, you can simply hit Ctrl-C. You will then see a prompt asking you if you want to shut down the SQL server.
Wait a while (it took approx. 5 minutes for mine) and once it completes, stop and restart the SQL service so that it is no longer running in this special mode, and you should be all set. With this procedure completed, we were able to start the SQL agent without problems.
Fixing a cluster that is offline
What do you do when you have a cluster that is completely offline? Have you ever encountered this problem? If so, you will know that you cannot manage your cluster using Cluster Administrator. In order to do so, Cluster Administrator must make a connection to the cluster - kind of hard if it's offline :-)
So, what to do? Well, you pull out your trusty cluster.exe command-line tool. Using cluster.exe, you can query for the status of the resources in your cluster by simply typing the command:
This will enumerate and list all resources as well as their status. From here you can bring an individual resource online (or fail it). For example, if your Cluster Network Name is offline, you can type
cluster.exe res "Cluster Network Name" /online
cluster.exe res "Cluster Network Name" /fail
Once the Network Name and IP address resources are online, you can continue by using the Cluster Administrator tool.