Tags » ‘Exchange 2007’Exchange Round Table at TechEd 2010
Categories: Exchange Server Microsoft Related
May 19th, 2010 by Scott
Jeff Guillet over at The EXPTA {blog} is hosting an Exchange Round Table event at TechEd 2010. If you happen to be going to TechEd and are interested in Exchange I would encourage you to attend. You can find more information over at his blog by going to the url TechEd 2010: Exchange Roundtable. Have a nice night! New Version of PFDAVAdmin
Categories: Exchange Server Microsoft Related
April 9th, 2010 by Scott
The MS Exchange team has released a new Version of PFDAVAdmin. Why is this important? If you’re like me and you need to manage or setup replication or what ever it is you want to do with Public Folders PFDAVAdmin is a great tool. I use this quite a bit when I’m migrating from Exchange 2003 to Exchange 2007. It allows me to set up replica’s rather quickly between the Exchange Servers. If you haven’t used this tool before I strongly encourage you to check it out! If you’re not sure what PFDAVAdmin is: OverviewUse the Exchange Server Public Folder Distributed Authoring and Versioning (DAV)-based Administration tool (PFDAVAdmin) to perform various management tasks related to public folders and mailboxes. The tool checks the permissions status of each public and mailbox folder and corrects any problems found. The ability to bulk export/import the permissions and replica lists make this tool invaluable in achieving greater productivity in managing public folders. The program can also reports content information of each public folder and mailbox folder such as the number of items in each folder, size of folder and most recent modification date of any item in the folder.
You can get the PFDAVAdmin file here: http://www.microsoft.com/downloads/details.aspx?familyid=635BE792-D8AD-49E3-ADA4-E2422C0AB424&displaylang=en
For the article posted at the Exchange Team Blog go here: http://msexchangeteam.com/archive/2010/04/09/454590.aspx
Have a great Weekend Everybody!
Disappearing NetApp LUNs when moving to EMC?March 10th, 2010 by ScottI was at a client site yesterday in the process of moving them off a NetApp Storage array and onto EMC Storage. My colleague and I ran into a very interesting problem and have no idea why it was happening. If anyone has any ideas please, do share. The setup was two Windows 2008 Servers with Exchange 2007 CCR split between two datacenters. The servers were using Snap Manager for Exchange and Snap Manager. There were four LUNs from the NetApp presented, three for databasae and one for the logs. The LUNs were attached via iSCSI. Since the Exchange CCR environment was running in the HQ Datacenter we started by getting the EMC agents installon the the Server in the DR Datacenter. The iSCSI LUNs from the NetApp were presented via Drive letters, there were four, three for the database and one for the logs. If you’re not familar with deploying EMC apps the first app to deploy is the EMC NaviHostAgent. When I installed the agent the server requested for a reboot. This is where things got really funky. When the server came back from a reboot the iSCSI disk drives from the NetApp were gone! No idea why. We scratched our heads and couldn’t figure out what happened. According to the NetApp management console the LUNs were presented. When we tried to remap the LUNs via Snap Manager it would state that the volume was already mapped to a drive on the server, but the Server could not see them! This was odd. We backed out the EMC NaviHostAgent and the LUNs reappeared but the drives were off line. I brought the drives back on line and everything worked again. We then started by reinstalling the EMC NaviHostAgent, no reboot was required this time and installed the EMCPowerPath application. When we came back from a reboot the drives from the NetApp were off line again, I brought them back on line and had both the EMC and the NetApp storage provisioned. Great, this is nice. We presented the EMC LUNs as mount points and started up replication again from the HQ Exchange Server. Once replication was caught up moved the cluster to the DR server to begin the same process on the HQ server thinking we had a fluke. Well, the exact same thing happened! When we installed NaviHostAgent no reboot was required. We then installed PowerPath, Had to reboot the server and the NetApp LUNs vanished! WTF right? Not again! We did the same procedure I mentioned above, removed PowerPath, removed NaviHostAgent, rebooted the Server in HQ. When it came back the NetApp LUNs were gone! No drive letters, no detection. Checked the iSCSI Initator configuration, and it was perfect, it was seeing the iSCSI targets for both the NetApp and the EMC. From the NetApps perspective the LUNs were provisioned. What in Windows 2008 was preventing the LUNs from being seen? I checked the Network settings via IPCONFIG and there was a “Local Area Connection 9″ that was there along with a Prod network and a iSCSI network. Looking at the network configuration only two NICs were active for the machine. No idea where the third NIC was coming from and by this time I was too tired to try to figure it out. Anyone out there have thoughts on that one? Anyway, after troubleshooting for about 5 hours between the two servers I proposed a Plan B. Since we had the NetApp storage (Thank God) and the EMC storage on the DR server I could create new Storage Groups and Databases on the DR server to the new EMC LUNs. Create new EMC LUNs on the HQ Exchange Server to reflect what was in DR and let CCR take care of the rest. Once the Storage Group and Databases were created I enabled replication only for the EMC Storage Groups (since the NetApp was off line on the HQ Server I couldn’t re-enable CCR) and started moving mailboxes. This worked fine, disaster averted. I was glad Plan B worked, but more complexing is why did the NetApp LUNs disappear? Anyone have an idea what may have happened with it? Again this was a Windows 2008 Server with Exchange 2007. The iSCSI network was correct, the NetApp was presenting the LUNs, when going into snap manager the LUNs said they were mapped. I tried to do a rescan of disks, nothing. Tried to take away the LUN and remap the LUN via NetApp management console and nothing worked. The Windows Firewall was turned off, disabled AV Software, nothing worked. Nothing would bring those LUNs back to the Windows 2008 server. Has anyone seen anything like this? Anyone have an idea on what happened? Please do share! Thanks, Exchange 2007 and Journaling to a 3rd party (external) mailbox
Categories: Exchange Server Microsoft Related
February 23rd, 2010 by Scott
I recently performed an Exchange 2007 upgrade for a client who was moving from Exchange 2003. As part of their compliance with some regulations they are required to journal the activity of certain mailboxes within their organization. Journaling in this situation was enabled on the database level so all users in the database will have all emails sent and received forwarded to an external 3rd party mail server. This was done through a send connector to the 3rd party’s domain. The problem the client was experiencing in Exchange 2007 was that all outbound emails originating internally were being sent to the external journaling provider however, all inbound emails were not being forwarded to the journaling provider. The client contacted the Journaling provider and from a conversation it was determined that when an inbound message arrived to the Exchange Mailbox Server, it would be forwarded to the journaling provider from the original sender, the original sender being someone from outside the organization. This immediately put up a red flag in my head. I started to think, Exchange receives an email to send to a 3rd party, from a person outside of this trusted organization. Exchange was refusing to send the message! So, the thought came into play, how to configure this thing to allow it to relay to the 3rd party email server. Anyone? Anyone? Ok, the solution was actually quite simple and once I understood what was happening it was easy to figure out. I simply setup an Internal Relay! Yup, that’s it. The Internal Relay will allow Exchange 2007 to receive emails for a specific domain, query Active Directory for the mailbox and deliver the mail for that domain if it is found internally. If the mailbox is not found internally Exchange will then Relay the email for the 3rd party mailbox server specified in the Send connector which was already configured above! Walla, problem solved! For more information on what an Internal Relay Domain is click here. Have a great day! Cisco Unity and Exchange 2007 on Windows 2008 R2February 19th, 2010 by ScottSo, an interesting call came to me last week regarding a client who was having some issues with Voicemails from Cisco Unity (I believe it was 7.0) transporting voice mails to Exchange. Their Exchange 2007 instance was moved from W2K8 to W2K8 R2 due to an issue they had with the W2K8 server. Not realizing that Unity (or Exchange) was not compatible with Windows 2008 R2 they started to have problems. Basically the problem they were having was when a voice mail was left for a user, it was not being delivered to the user. Voicemails would pile up on the Unity server. The recommendation was to reinstall Exchange 2007 on a W2K8 server WITHOUT R2. The client decided to take a path to resolve the issue but I am not certain what they did. On another note Exchange 2007 is not supported on Windows 2008 R2 yet, however I have heard rumors that if you install Exchange 2007 SP2 on Windows 2008 R2 if you run the install in Windows Vista Compatibility mode the install will work. When will Exchange 2007 officially support Windows 2008 R2? Well, Exchange 2007 SP3 will allow support for Windows 2008 R2. Exchange 2007 SP3 should be released some time this year (2010). Moral of the story, do not put Exchange 2007 on W2K8 R2, and do not use Unity with Windows 2008 R2. I also understand that Cisco Unity does not support Windows 2008 R2 domain controllers. Exchange 2007 SP2 will support Windows 2008 R2 domain controllers. So, take your pick, but you can’t use Unity to query W2K8 R2 DCs. I hope this helps some people out there! Thanks for visiting. My Client Visit Yesterday Part 2
Categories: Exchange Server Microsoft Related
February 12th, 2010 by Scott
So, yesterday I was out at a client site to review their Exchange 2007 deployment. In my previous post I talked about how the Subnet the Exchange 2007 servers were in did not have the IP subnet associated with an AD site. Well, I did come across another interesting issue that was a bit more troublesome. The client is deploying an Exchange 2007 SP2 environment leveraging a Single Copy Cluster (SCC) and two CAS/HUB servers. While testing the failure over process of the SCC we came to the point where using the manage clustered mailbox command in the Exchange Management Console or the Exchange Management Shell would not work. We were receiving an error message that the Database failed to initialize. The error log was huge, errors on creating the D drive (where the database was located), errors opening the database, mounting the database, it just wasn’t working! I then suggested to go back and use the MS Failover Cluster Management tool. We took a node off line, and failover worked. How Odd! This appeared to be an issue with permissions on the servers. Something was prevent Exchange from performing the failover. We then tried another failover vial the managed clustered mailbox command and I noticed that the shared disk drives were attempting to fail over to the passive node but they couldn’t! We then proceeded to check permissions into the Windows Cluster and Exchange Cluster, adjusted a few settings but nothing worked. Well, I then asked, is there a Group Policy blocking any time of assignment to “Manage auditing and security log”, he said no. We checked Group Policy to be certain and there was nothing configured. I then asked him to take a look at the local security policy on the system, sure enough, only the Administrators were in the group Manage auditing and security log. Once adding the Exchange Servers to this group on each system the Single Copy Cluster was able to fail over with no problems! I am not certain as to why the Exchange Servers did not get added to the local security policy, there was nothing in group policy or anything on the system to over write this to my knowledge. But none the less, it is very important to make sure the Exchange Servers do have access to the security setting. Either way it was quite an interesting day at my client site, a few more issues came up but nothing as notable as the ones discussed here. Hope you have a great day! My Client Visit Yesterday Part 1February 11th, 2010 by ScottSo, I was out at a client site yesterday to review the work they have completed so far on their Exchange 2007 deployment. There were two issues that we came across that were unique that I thought I would mention to the population out there. Hopefully this information will be able to help someone. The first problem I noticed was the error message that stated Exchange was not part of an active directory site. This caused me to think, why would an error come up like this. My first instinct was to do a Gpresult /r (Windows 2008) which listed out all the information about the computer and user. The Computer said it belonged to the site Default-First-Site-Name. Ok, so the server was recognizing that it was a member of the AD Site, but why was exchange balking at the issue? Well, I asked the IT Admin to open up Active Directory Sites and Services and took a look in there. Looking over AD Sites and Services I noted the client had only one site configured, Default-First-Site-Name. Thinking a little bit more about the situation I asked to see what subnets were configured for the site. Well, upon review the site only had two subnets assigned to it. Neither one of these Subnets included the subnet Exchange 2007 was in. Talking to the Admin about this I learned that they had the same issue on the Hub Transport Servers and had to manually configure AD using ADSIEdit to insert the proper site name for the server to use! Eww, not sure how this will impact their environment in the long run but when installing Exchange this should all be done automatically. So, I had the admin add the Subnet to the AD Sites and Services and rebooted the mailbox servers, error gone, problem solved! The moral of the story above? Make sure that you have your AD Sites and Services properly configured prior to deploying Exchange. Oh yea, don’t forget, you need to have a domain Controller in the same AD Site as Exchange. How the client ever got Exchange working is beyond me. The workstation was seeing the AD Site but Exchange was not, hence the error. Update Rollup 2 for Microsoft Exchange Server 2007 Service Pack 2
Categories: Microsoft Related
January 25th, 2010 by Scott
Exchange 2007 SP2 Failed because of ‘beremote’
Categories: Microsoft Related
November 6th, 2009 by Scott
I was upgrading Exchange 2007 with Exchange 2007 SP2 on a client exchange server this evening and came across the error “Setup cannot continue with the upgrade because the ‘beremote’ () process (ID: 1876) has open files. Close the process and restart Setup. The problem was a result of having Veritas Backup installed on the Exchange 2007 server. The service “Backup Exec Remote Agent for Windows Servers” was locking the process and preventing the Exchange 2007 SP2 setup from running. I had to go into Services and stop the “Backup Exec Remote Agent for Windows Servers” service. Once I stopped this service I was able to proceed with the installation of Exchange 2007 SP2. Beware of the Snow Leopard.
Categories: Microsoft Related
October 15th, 2009 by Scott
I had a call with a client yesterday regarding their Exchange 2007 mailbox server crashing with Dr. Watson errors. Their deployment is a Single Copy Cluster and to make matters worse when the error was occurring the cluster would not fail over. This problem started for them when Mac users upgraded to the newest version of Snow Leopard. Based on conversations I had with them I’m guessing Snow Leopard was causing a high level of traffic to the Exchange 2007 mailbox server and caused the server to fail. I have actually seen this as well when an Outlook plug-in goes rouge and causes a high level of RPC connections to the mailbox server. The mailbox server in essence becomes unresponsive and users can not connect. Asking about their updates they had not updated the Exchange servers with any Exchange roll ups for some time. I advised them to update their servers, which they did by deploying RU 9. They also asked Mac users not to use Snow Leopard for awhile until they get this thing out of control as their mailbox server was crashing every 20 minutes give or take. As a note the admin there said he was also familar with a another Exchange admin having the same experience. This may not be directly related to Snow Leopard and Exchange not being updated but there is a chance. I’m thinking the RU9 will help, but I’ll let you know if the problem continues! |
|