Solved

Exchange 2013 CU1 prerequisite error regarding Exchange 2007 SP3

Posted on 2013-05-31
5
1,777 Views
Last Modified: 2013-06-11
I  can't seem to get an Exchange 2013 install  to recognize that the Exchange 2007 on the network is honest to goodness SP3 rollup 10.

Our current server runs SBS 2008.  I have Exchange 2007 fully updated with Service Pack 3 and Rollup 10. I've gone back and  verified it under Program and in the Shell and Console. It says Rollup 10 is installed and the build number is 8.3.298.3.

The new server is a separate box with Microsoft 2012 Standard. I have 3  virtual servers running via hyper-V--one as a second DC, one with Sharepoint 2013 and SQL Server 2012, and one for Exchange 2013. All are currently pointed to SBS server as the DNS server (the second DC also points to itself as an alternative).  The SBS 2008 Server still has all the FSMO roles

The first two haven't been a problem with setting up, but for the Exchange install constantly fails with just one Error:

 [REQUIRED] All Exchange 2007 servers in the organization must have Exchange 2007 SP3 or later installed. The following servers don't meet this requirement: [MySBSServerName]

 The domain level is 2003, (I haven't read advice to bump it up, but it wouldn't be a problem if I had to).  I am using the Exchange 2013 CU1 for the install, which should coexist with 2007. . Once everything is finished and everyone moved over, I'll transfer the main roles to the new DC and retire the SBS server.

 Could this error be because it's a SBS server? Has anyone encountered this or could point me in the right direction?

Many thanks!
0
Comment
Question by:rjmoseroashf
  • 3
  • 2
5 Comments
 
LVL 63

Expert Comment

by:Simon Butler (Sembee)
Comment Utility
SBS will not be the problem.
Are the FOREST and the DOMAIN at Windows 2003? That is the minimum required.
If you run the rollup again, does it do anything? It could be that something hasn't been stamped correctly in the registry or domain.

Simon.
0
 

Author Comment

by:rjmoseroashf
Comment Utility
Yep, both are at 2003. No difference when I ran the rollup 10 again.  Going to  re-install service pack 3 the moment I have downtime in hopes that will jog something.
0
 
LVL 63

Expert Comment

by:Simon Butler (Sembee)
Comment Utility
You will need to remove the rollup before you can reinstall the service pack, although I don't think you will be able to reinstall it unless the installer detects something is missing.

Simon.
0
 

Accepted Solution

by:
rjmoseroashf earned 0 total points
Comment Utility
After much trial and error, I've finally cleared the issue.

Steps that had no effect for me on it (to be helpful in case someone else has a similar issue):

Re-installing the rollups had no effect, and while I did run the setup.com /prepareschema, and then setup /preparead again, no difference.

Disabling Symantec Endpoint and Forefront Protection for all roll-ups, Active Directory prep, and attempted 2013 coexistence install (although I'd recommend doing that anyway for them, especially the first time). No change.

Changing the registry keys to reflect Service Pack 3 rollup 10 (the correct versions were listed as unpacked, but not configured) at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\v8.0\<Role>\ConfiguredVersion. Before taking such a measure,  I verified that the files in the Exchange bins folder (like store.bin) were all rollup 10 build. I also verified it the Exchange Management Console using GCM exsetup |%{$_.Fileversioninfo}.

While this did not affect the issue, it did lead me to the solution. Because putting in get-exchangeserver, the result next to  AdminDisplayVersion was "Version 8.1 (Build 30240.6)'". Service Pack 1 Rollup 6. Hmm.

Looking through the exchange setup log on the 2013 server (previously I had just looked at the error/failure reporting sections. Before for that is the expansive list of its starting, evaluated, and finished prerequisite checks. There I found exactly "Version 8.1 (Build 30240.6)". From other blogs I had learned the AdminDisplayVersion wasn't the reality of the version: it just displays  whatever's listed in the Active Directory. Exchange 2013's prerequisite's check depends entirely on info provided Active Directory, not what's actually running.

At some point in the past (SP1 1 Rollup 6 in my case), Exchange had stopped updating the Active Directory exchange attributes when updating itself--information needed for the 2013 install.  The problem source existed in the original place I looked--the Active Directory Service Interface using adsiedit.msc. I'd just been looking in the wrong place.

 The forest and domain version number for exchange were perfectly correct. What wasn't was two attributes on the exchange server object. The first was easy. The second, not so much.

Solution

Here's a handy page of Exchange: build numbers: http://social.technet.microsoft.com/wiki/contents/articles/240.exchange-server-and-update-rollups-build-numbers.aspx

Right-click ADSI Edit at the top of the mmc. Right click and choose Connect to, then  Select a well know Name Context and pick Configuration. Then okay,

Expand CN=Configuration], CN=Services, CN= Microsoft Exchange, CN=[ExchangeDomain], CN=Administrative Groups, CN=Exchange Administrative Group (FYD...), CN=Servers, CN=[Your Exchange Server]. Right click your exchange server name listed and select Properties. Scroll to serialNumber. If it does not say it already, and you are POSITIVE your Exchange server  is operating on SP3 rollup 10 as exampled earlier in this post, Edit it and add Version 8.3 (Build 30298.3) and remove the one that was there.

That changes get-exchangeserver AdminDisplayVersion to exactly that (I almost think that if you changed it to fluffybunnies, it would say that); that line is simply a reflection of  what's listed in ADSI. More importantly, the server 2013 log stops showing the older version when evaluating it's minimum and existing version rules.

BUT IT STILL FAILS WITH THE EXACT SAME ERROR. 2007 is not service pack 3 etc (I had actually done this before changing the registry.] The evaluations lists absolutely no specific reason why. The error still states [sbs/exchangeserver] is at fault.

While I believe the above does need done since the Exchange 2013 install specifically pulls it as a prereq, there's one more attribute that needs changed, and it's in the same list as serialNumber. This is where it got fun, with a mix of deduction and luck.

It occurred to me the attribute versionNumber, also in [exchangeserver] properties had not changed at all, not once through all the changes and updates. It stuck out as 'versions' had been the issue from the start, even though the number there was entirely unfamiliar. But a quick past in Google informs that it was associated with SP 1, rollup 6. Let's change it.

And then, of course, does it list nowhere on the net for a list versionNumber values. I found a forum poster that listed them for the original service pack 1 and 2. But service pack 3? Nada. Evidently if you run Edge server, you can export a new subscription file and the integer will be right in there. I do not, and no hub or transport export I tried had what I was looking for.

If I ever meet the writer of this article, I owe him a beer. It instructs how to turn a build  number into binary sections and then a decimal integer (or rather the other way around, but i just reversed the process.) http://blogs.msdn.com/b/pcreehan/archive/2009/09/21/parsing-serverversion-when-an-int-is-really-5-ints.aspx .
 
I converted the sections of the Rollup 10 build number into binary, added first four bits and middle flag as instructed and put t together to form a new decimal integer. I came up with 1912832298. I could be off  as I'm no parsing pro, it was quite late, and i'd had no food all day, so it's entirely possible that any integer above a certain level will clear it. But as soon as I put in that in versionNumber and retried,  the prereq error cleared. MS Exchange 2013 installed on the new server with no new problems, and no issues with SBS.
0
 

Author Closing Comment

by:rjmoseroashf
Comment Utility
Worked on the issue for a few days and figured out the solution, then posted in the case it might help someone else.
0

Featured Post

How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

Join & Write a Comment

We are happy to announce a brand new addition to our line of acclaimed email signature management products – CodeTwo Email Signatures for Office 365.
Scam emails are a huge burden for many businesses. Spotting one is not always easy. Follow our tips to identify if an email you receive is a scam.
In this Micro Tutorial viewers will learn how to use Boot Corrector from Paragon Rescue Kit Free to identify and fix the boot problems of Windows 7/8/2012R2 etc. As an example is used Windows 2012R2 which lost its active partition flag (often happen…
how to add IIS SMTP to handle application/Scanner relays into office 365.

744 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

16 Experts available now in Live!

Get 1:1 Help Now