On December 30, 2008, I finished up on my testing for MCITP: Enterprise Messaging Administrator for Exchange 2007. As with most things, I put it off much longer than I should have, and I'm glad to be done with it. But for anyone contemplating going through it, here's my take on it:
Exam 70-236 for MCTS on Configuring Exchange 2007 - This was by far the hardest exam of the three required for MCITP. Of course passing just this one gives you MCTS, so that's something. But hopefully without giving away too much to violate any NDA's, I'll say that when you sit this one, you need to know where you do things in Exchange, what permissions you need to do it, and know your Powershell cmdlets in the Exchange Management Shell.
Exam 70-237 for MCITP on Designing Exchange 2007 - To me this seemed to be the easiest of the exams. If you have working knowledge of what it takes to setup Exchange 2007 and what the roles do and why you need them, then this one shouldn't be too difficult.
Exam 70-238 for MCITP on Deploying Exchange 2007 - I thought this one was a bit tougher than 237, however I scored the highest on this one. It really expanded on what was included in 237. It seemed to require you to think through the questions a bit more.
Of course, with Microsoft exams, not every question will always make perfect sense. That is just the way it is. Overall though, I didn't think these exams were half bad. Just wish I hadn't put it off for so long...
As far as study materials go, I used the following study guides:
MCTS Self-Paced Training Kit (Exam 70-236): Configuring Microsoft Exchange Server 2007
Orin Thomas, Ian McLean, Microsoft Press, Hardcover, Bk&CD edition, Published November 2007, 896 pages, ISBN 0735624100
MCITP: Microsoft Exchange Server 2007 Messaging Design and Deployment Study Guide (70-237 and 70-238) Rawlinson Rivera, Sybex, Published 2008, Bk&CD edition, ISBN 047018146X
For the most part, I would recommend either of these books. Both had a lot of useful information, and were good as review material. There were some minor errors here and there, but nothing to really throw you off for the exams.
Now on to Microsoft Certified Master. If only....
Tuesday, January 6, 2009
Time for my yearly post! Blogging again...
No, I'm not even going to talk about how long it's been since I posted something - anything for that matter. I know, I'm a horrible blogger... I would say I'd make a resolution to do better, but I've already got my New Year's resolution: 1920x1200. Get it? Resolution, as in display settings??
I saw that somewhere, the exact location now forgotten, and had to use it. Sorry. I'll try not to make lame jokes like that again. But maybe you can understand why I'm in IT based on my prowess as a joke teller. I don't expect to be able to quit my day job any time soon...
Ok, onto a real post....
I saw that somewhere, the exact location now forgotten, and had to use it. Sorry. I'll try not to make lame jokes like that again. But maybe you can understand why I'm in IT based on my prowess as a joke teller. I don't expect to be able to quit my day job any time soon...
Ok, onto a real post....
Thursday, April 24, 2008
Has it really been this long?! Renewing Exchange Certificates...
On a couple of fronts there has been some passing of time... First, I admit that, yet again, I've sorely neglected my blog... I'll truly try to start doing better! :-)
It's also been around a year since I installed Exchange 2007. As such, I started to get MOM notifications about the certificate on my Hub Transport server expiring. So, I dig around and find a couple of blogs from others that cover the subject to start reading up on it. Then I head to the Exchange Help to see what it has to say. Ultimately, I come up with the following:
In this instance, my certificate renewal deals only with the certificate for SMTP services on the HT server. This is the original automatically generated certificate from the install. (Side note: My CAS server has a cert I installed from our internal CA, and it's good for another year.) So, from my reading I determine that I need to renew, or more specifically, replace, by running the following cmdlet in the shell:
New-ExchangeCertificate
This prompts me to confirm that I want to overwrite the existing default SMTP certificate, which I do. And that pretty much does it...
Except... I now start to notice my outbound edgesync queue starting to grow. Once that initial "Oh crap!!" feeling passes I start to investigate why this is occuring. That leads me to my Edge server which is reporting that it doesn't have any information about the certificate now in use on the HT server. So, I decide to go back to the HT server and run a quick Start-EdgeSynchronization. So the sync runs (successfully!) and the configuration information is updated on the Edge server. As soon as that takes effect, my queue clears right up!!
Job done.
It's also been around a year since I installed Exchange 2007. As such, I started to get MOM notifications about the certificate on my Hub Transport server expiring. So, I dig around and find a couple of blogs from others that cover the subject to start reading up on it. Then I head to the Exchange Help to see what it has to say. Ultimately, I come up with the following:
In this instance, my certificate renewal deals only with the certificate for SMTP services on the HT server. This is the original automatically generated certificate from the install. (Side note: My CAS server has a cert I installed from our internal CA, and it's good for another year.) So, from my reading I determine that I need to renew, or more specifically, replace, by running the following cmdlet in the shell:
New-ExchangeCertificate
This prompts me to confirm that I want to overwrite the existing default SMTP certificate, which I do. And that pretty much does it...
Except... I now start to notice my outbound edgesync queue starting to grow. Once that initial "Oh crap!!" feeling passes I start to investigate why this is occuring. That leads me to my Edge server which is reporting that it doesn't have any information about the certificate now in use on the HT server. So, I decide to go back to the HT server and run a quick Start-EdgeSynchronization. So the sync runs (successfully!) and the configuration information is updated on the Edge server. As soon as that takes effect, my queue clears right up!!
Job done.
Tuesday, September 18, 2007
Handy Dandy Exchange 2007 Cmdlet Guide
Want a quick reference for the most common Exchange 2007 Powershell cmdlets? Check out this download available from Microsoft that fits the bill: http://www.microsoft.com/downloads/details.aspx?familyid=01a441b9-4099-4c0f-b8e0-0831d4a2ca86&displaylang=en&tm
Want more Exchange management shell goodness to read about? Then check out the whitepaper here: http://technet.microsoft.com/en-us/library/c0743a9c-8434-437f-8911-6e38f7ccdac3.aspx
Enjoy!
Want more Exchange management shell goodness to read about? Then check out the whitepaper here: http://technet.microsoft.com/en-us/library/c0743a9c-8434-437f-8911-6e38f7ccdac3.aspx
Enjoy!
Wednesday, August 8, 2007
Exchange 2007 Monitoring with MOM 2005... Case of the missing cmdlet!
Being that I work with "THE" John Hann (MOM MVP), there never was any question as to which management product I would use to watch over my Exchange servers. And, so, we finally installed the MOM agents on them and watched the events roll in....
For a nice read and a detailed description of how to get MOM 2005 working with Exchange 2007 and what MOM will do for you, check out Anderson Patricio's article series at MSExchange.org:
Monitoring Exchange Server 2007 using MOM 2005 - Part 1, Part 2, and Part 3
Well, in the events, we come to find that the MOM scripts are failing in trying to test connectivity to OWA, ActiveSync, and the like. So as directed I run a PowerShell script called New-TestCasConnectivityUser.ps1 from the Exchange 2007 scripts directory. This creates a system test mailbox for just this purpose. However, the messages continue to come in and now direct you to run a cmdlet called Set-CasConnectivityCredentials in order "to store this user's credentials for use in testing the Client Access services." Sounds easy enough, except this cmdlet seems not to exist, anywhere......
After basic troubleshooting on the issue (like making sure I spelled it correctly), I start digging in to figure exactly what is going on and why it's calling for a missing cmdlet. I decide to run a couple of the test- cmdlets manually that MOM is having a problem with. Upon doing so, it basically tells me that it has authentication issues with the user I created via the script. I end up checking the account in Active Directory and find it locked out. I unlock it and yet the test cmdlets still fail. And now when all else fails, I do what the error in the cmdlet output tells me to do, which in this case is to run the script again to verify the user exists.... Which of course makes no sense because it created it successfully and I can see it in AD, but I do what it says anyway. So when I re-run it, it does a reset on the credentials of the test account created previously. And wouldn't you know that fixes the problem!! Now the test- cmdlets will run when done manually and after clearing the events in MOM, they don't come back!
The point here isn't that the solution was that difficult to find or figure out, but rather it is difficult to understand what direction you're supposed to go in when you're being told by the product itself, in this case MOM, what to do but are completely unable to do so because it doesn't exist. Lesson learned is: Sometimes you just have to think outside of the box, the MOM alert box that is.....
For a nice read and a detailed description of how to get MOM 2005 working with Exchange 2007 and what MOM will do for you, check out Anderson Patricio's article series at MSExchange.org:
Monitoring Exchange Server 2007 using MOM 2005 - Part 1, Part 2, and Part 3
Well, in the events, we come to find that the MOM scripts are failing in trying to test connectivity to OWA, ActiveSync, and the like. So as directed I run a PowerShell script called New-TestCasConnectivityUser.ps1 from the Exchange 2007 scripts directory. This creates a system test mailbox for just this purpose. However, the messages continue to come in and now direct you to run a cmdlet called Set-CasConnectivityCredentials in order "to store this user's credentials for use in testing the Client Access services." Sounds easy enough, except this cmdlet seems not to exist, anywhere......
After basic troubleshooting on the issue (like making sure I spelled it correctly), I start digging in to figure exactly what is going on and why it's calling for a missing cmdlet. I decide to run a couple of the test- cmdlets manually that MOM is having a problem with. Upon doing so, it basically tells me that it has authentication issues with the user I created via the script. I end up checking the account in Active Directory and find it locked out. I unlock it and yet the test cmdlets still fail. And now when all else fails, I do what the error in the cmdlet output tells me to do, which in this case is to run the script again to verify the user exists.... Which of course makes no sense because it created it successfully and I can see it in AD, but I do what it says anyway. So when I re-run it, it does a reset on the credentials of the test account created previously. And wouldn't you know that fixes the problem!! Now the test- cmdlets will run when done manually and after clearing the events in MOM, they don't come back!
The point here isn't that the solution was that difficult to find or figure out, but rather it is difficult to understand what direction you're supposed to go in when you're being told by the product itself, in this case MOM, what to do but are completely unable to do so because it doesn't exist. Lesson learned is: Sometimes you just have to think outside of the box, the MOM alert box that is.....
Thursday, August 2, 2007
Excited about Exchange 2007 SP1?
I know I am, and you should be too. Why? Because it really adds to the feature set and functionality of the RTM version. Like what? Well, the OWA improvements are going to be fantastic. And then there is the new cluster model for Standby Cluster Replication, or SCR, which will be a great feature for disaster recovery scenarios.
For more info on some of the features, check this writeup at the Exchange Team blog:
Talking Exchange 2007 SP1....
But one feature that I think is really going to help on the install of Exchange 2007 are the changes in the AD requirements for the setup and domain prep processes. Basically, the setup process would fail if it couldn't reach a domain in the forest, or if it ended up trying to talk to any Win2k DC/GC in a domain even when there was an available Win2K3 SP1 DC/GC available. This was even in domains where you weren't even trying to prepare them!?! With E2007 SP1, however, it will simply ignore these "problems." These scenarios and the SP1 improvements are described in detail here: A Setup Prerequisite Change in Exchange 2007 SP1
Boy do I wish the RTM version had worked like that!!! This was something that caused some major headaches in trying to get E2007 installed in my AD environment. Now, as it just so happened, we were already in the works on doing an AD infrastructure upgrade anyway. We were able to expedite that process and were finally able to get our AD prepped and Exchange installed. Of course in the middle of all that, when we did the schema updates it broke replication between the remaining Win2k servers and the 2003. It's a known issue and is addressed with a hofix as described here: http://support.microsoft.com/kb/824873/en-us. I throw this out there so you can be aware of this as a potential side effect you could encounter.... For us the install worked out OK in the end. But there are going to be many environments where for either technical or monetary reasons the AD environment cannot be adjusted so quickly.
This really begs the question then as to whether someone considering Exchange 2007, either as a new install or a migration from 2003, should do it now or wait for at least SP1???? I can't answer that, it's totally dependent on your environment and circumstances. All I can say on the matter is that even though my install of Exchange 2007 brought many challenges, I am very glad we moved forward on it as early as we did. I'd do it all over again if given the chance! But that doesn't make me any less excited about SP1....
For more info on some of the features, check this writeup at the Exchange Team blog:
Talking Exchange 2007 SP1....
But one feature that I think is really going to help on the install of Exchange 2007 are the changes in the AD requirements for the setup and domain prep processes. Basically, the setup process would fail if it couldn't reach a domain in the forest, or if it ended up trying to talk to any Win2k DC/GC in a domain even when there was an available Win2K3 SP1 DC/GC available. This was even in domains where you weren't even trying to prepare them!?! With E2007 SP1, however, it will simply ignore these "problems." These scenarios and the SP1 improvements are described in detail here: A Setup Prerequisite Change in Exchange 2007 SP1
Boy do I wish the RTM version had worked like that!!! This was something that caused some major headaches in trying to get E2007 installed in my AD environment. Now, as it just so happened, we were already in the works on doing an AD infrastructure upgrade anyway. We were able to expedite that process and were finally able to get our AD prepped and Exchange installed. Of course in the middle of all that, when we did the schema updates it broke replication between the remaining Win2k servers and the 2003. It's a known issue and is addressed with a hofix as described here: http://support.microsoft.com/kb/824873/en-us. I throw this out there so you can be aware of this as a potential side effect you could encounter.... For us the install worked out OK in the end. But there are going to be many environments where for either technical or monetary reasons the AD environment cannot be adjusted so quickly.
This really begs the question then as to whether someone considering Exchange 2007, either as a new install or a migration from 2003, should do it now or wait for at least SP1???? I can't answer that, it's totally dependent on your environment and circumstances. All I can say on the matter is that even though my install of Exchange 2007 brought many challenges, I am very glad we moved forward on it as early as we did. I'd do it all over again if given the chance! But that doesn't make me any less excited about SP1....
Tuesday, July 31, 2007
"Notes" from the field... Send Connectors
Lotus Notes, that is.... You see, I recently headed up a project to assist a subsidiary company of ours who had requested help with a migration from Lotus Domino/Notes to Exchange/Outlook. This was very interesting for me, especially as I'd never really used Notes or worked on a Domino server. But it felt very good to assist these folks in getting off of that platform and migragting them over to Exchange 2007.
To do the actual mail migration we ended up using a combination of the Microsoft Transporter and then BinaryTree's CMT Universal product. Both products work, and work very well. The only reason we had to go beyond MS' product was because some of the users had items with problems that Transporter just couldn't get past and would fail on. CMT would hit the items and just skip them and move on. For our case this was ok, as most of the problems were with very old calendar appointments anyway. If anyone would like more information about these products please leave a comment and I'll get back to you.
What I really wanted to talk about in this post wasn't so much the actual Notes migration itself, but a rather interesting side item regarding message size restrictions on Send Connectors..... To get to that I need to let you know that as part of the overall project, we also had to setup a new network fax solution as well. To this end, I chose to go with GFI Faxmaker. This was essentially another first for me as I've not dealt with a fax server product since about 1997 which was RightFax and it was running on NT 3.51.... So in setting up GFI Faxmaker (which I must say seems like a pretty good product, thus its' many customer choice awards) to work with Exchange 2007, I had to create two send connectors for Exchange to route faxes to the fax server. And don't get me wrong, that all worked like a champ.
The issue came when everyone was back to work and started trying to send emails (normal SMTP emails, NOT faxes) with attachments. Anything over 10MB wouldn't send. So of course I start looking at message size limits. I check the mailbox settings for the user in question and there are no limits imposed. I then check the default Internet SMTP connector in the Exchange Management Shell and notice that of course the 10MB default setting for MaxMessageSize is what it's showing. So I bump that up to 150MB and try sending again. Still doesn't work. From there I start bumping any maximum sizes for messages or attachments in receive connectors and at the organization level. Nothing works. I'm stumped. So, as I do when I find myself in that situation, I call in to MS Support. I finally get connected to the support engineer who starts going through all of the settings that I previously mentioned with me, to which he says "It should be working, but hold on and let me check on this." When he gets back on the line he recommends that we now also go and change the MaxMessageSize on the send connectors that I had setup to work with GFI Faxmaker. And don't you know that as soon as I upped those settings as well, the attachments started flowing.
I was aware that whole time that the fax connectors had the 10MB setting, but I just didn't see how they could be affecting trying to send out to the Internet, or even to another local Exchange user for that matter. I now understand this is the default behavior and know how to work around it. And knowing is half the battle....
Hope this helps someone else oneday. And if not, then I at least hope it kept your interest....
To do the actual mail migration we ended up using a combination of the Microsoft Transporter and then BinaryTree's CMT Universal product. Both products work, and work very well. The only reason we had to go beyond MS' product was because some of the users had items with problems that Transporter just couldn't get past and would fail on. CMT would hit the items and just skip them and move on. For our case this was ok, as most of the problems were with very old calendar appointments anyway. If anyone would like more information about these products please leave a comment and I'll get back to you.
What I really wanted to talk about in this post wasn't so much the actual Notes migration itself, but a rather interesting side item regarding message size restrictions on Send Connectors..... To get to that I need to let you know that as part of the overall project, we also had to setup a new network fax solution as well. To this end, I chose to go with GFI Faxmaker. This was essentially another first for me as I've not dealt with a fax server product since about 1997 which was RightFax and it was running on NT 3.51.... So in setting up GFI Faxmaker (which I must say seems like a pretty good product, thus its' many customer choice awards) to work with Exchange 2007, I had to create two send connectors for Exchange to route faxes to the fax server. And don't get me wrong, that all worked like a champ.
The issue came when everyone was back to work and started trying to send emails (normal SMTP emails, NOT faxes) with attachments. Anything over 10MB wouldn't send. So of course I start looking at message size limits. I check the mailbox settings for the user in question and there are no limits imposed. I then check the default Internet SMTP connector in the Exchange Management Shell and notice that of course the 10MB default setting for MaxMessageSize is what it's showing. So I bump that up to 150MB and try sending again. Still doesn't work. From there I start bumping any maximum sizes for messages or attachments in receive connectors and at the organization level. Nothing works. I'm stumped. So, as I do when I find myself in that situation, I call in to MS Support. I finally get connected to the support engineer who starts going through all of the settings that I previously mentioned with me, to which he says "It should be working, but hold on and let me check on this." When he gets back on the line he recommends that we now also go and change the MaxMessageSize on the send connectors that I had setup to work with GFI Faxmaker. And don't you know that as soon as I upped those settings as well, the attachments started flowing.
I was aware that whole time that the fax connectors had the 10MB setting, but I just didn't see how they could be affecting trying to send out to the Internet, or even to another local Exchange user for that matter. I now understand this is the default behavior and know how to work around it. And knowing is half the battle....
Hope this helps someone else oneday. And if not, then I at least hope it kept your interest....
Subscribe to:
Posts (Atom)
_538.gif){kind=small}
