none
Exchange 2010 RTM to SP2 and GAL Segregation

    Question

  • Hi Folks

    We recently upgraded from Exchange 2007 SP2 which was configured for GAL segregation to Exchange 2010 RTM RU5. We were aware that there would be certain issues that we would face, for example, the GlobalAddressList2 attribute being utilised and that was addressed as soon as E2K10 was introduced. We also know this is not a supported setup.

    Apart from that everything continues to operate as before. We now want to move to SP2 so we can use ABPs and be supported. From much reading we understand that this could result in some pretty major problems with the existing GAL segregation and the potential to expose tenants to each other which is something that is just not an option so we are quite reluctant to make the jump. We have also read that customers could receive the bookmark is invalid and be presented with a blank GAL (something that online clients will see as opposed to those using the OAB) Does anyone have any step by step details in regard to how we can make the jump to SP2 so we can become fully supported and use a version of Exchange that is truely multitenant. We have read that the GAL segregation should be removed and also that the MsExchQueryBaseDN should be removed completely from all users AD attributes. I am in interested to hear from anyone who has experience with this and appreciate any guidance you can provide.

    We are also looking at ripping out our existing Lync deployment and installing the Lync Multi-Tenant Hosting Pack so we are doing things the right and supported way! Also SP2 is a pre-requisite for the UM side of the LMTHP.

    Any advice, guidance would be appreciated as usual

    Thanks

    Adam

    Wednesday, February 15, 2012 6:58 PM

Answers

  • 2010 SP2 fixes that specific issue. Each time new-globaladdresslist is used in SP2 it makes sure the two attributes are in sync. Basically you should only use 2010 EMS to create GAL's once you have 2010 in place. Whatever you do, test thoroughly though - the ACL based config you have in 2007 is probably very similar to what you have in 2010 RTM, and so the process there should help you, but it's important to test thoroughly. You have a period of co-existence of ACL's and ABP's ahead which is possible, but hard. So if you don't have a test lab, build one to test changes you plan on making.

    • Marked as answer by Adam42 Wednesday, February 15, 2012 9:00 PM
    Wednesday, February 15, 2012 8:17 PM
  • I won't use the word 'easy', but I'm glad you did. ;-)

    It's the install of the first 2010 server that requires full access to objects like the GAL, so if you already have 2010 in, adding a service pack shouldn't require changing anything (though you need to test, in case I didn't already say that 10 times...).

    Yes to your nutshell summarization. Looks good to me.

    You should move OABgen to 2010, there are lots of bugs fixed and performance improvements in 2010 SP2. For one, in 2007 I bet you build OAB's from AL's, not GAL's correct? We fixed that in 2010 SP2.

    And yes, go straight to SP2. Don't make it harder than it needs to be and make it a multi-step migration.

    • Marked as answer by Adam42 Friday, February 17, 2012 8:11 AM
    Thursday, February 16, 2012 10:16 PM

All replies

  • Hi Steve

    Yes of course I have seen those blog articles but that doesn't answer my specific question.

    Thanks

    Adam

    Wednesday, February 15, 2012 7:41 PM
  • Migrate to Exchange 2010 Address Book Policies from Exchange 2007 Address List Segregation - http://technet.microsoft.com/en-us/library/hh529930.aspx 
    Wednesday, February 15, 2012 7:43 PM
  • Thanks Greg. I dont see any mention of the attribute GlobalAddressList2 in the article and we are at Exchange 2010 RTM as opposed to Exchange 2007. We had to populate this attribute with our existing GAL DNs taken from the globaladdresslist atttribute on CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=hosterdomain,DC=com . Should we just remove those as I am assuming the ABP take care of all that with SP2?

    Thanks

    Adam

    Wednesday, February 15, 2012 8:11 PM
  • 2010 SP2 fixes that specific issue. Each time new-globaladdresslist is used in SP2 it makes sure the two attributes are in sync. Basically you should only use 2010 EMS to create GAL's once you have 2010 in place. Whatever you do, test thoroughly though - the ACL based config you have in 2007 is probably very similar to what you have in 2010 RTM, and so the process there should help you, but it's important to test thoroughly. You have a period of co-existence of ACL's and ABP's ahead which is possible, but hard. So if you don't have a test lab, build one to test changes you plan on making.

    • Marked as answer by Adam42 Wednesday, February 15, 2012 9:00 PM
    Wednesday, February 15, 2012 8:17 PM
  • OK great thanks for all the info. We will we sure to test this lot out as I dont like surprises!

    Adam

    Wednesday, February 15, 2012 9:00 PM
  • Sorry Greg one more thing after some initial reading and based on the fact we already have Exchange 2010 RTM deployed we could do the following:

    1. Follow step 1 to configure the permissions of the default GAL back to what they should be normally
    2. Step 2 - we already have RTM deployed so at this point we could upgrade to SP2 on our servers 
    3. Secure the default GAL and delete created lists (room, contacts etc)
    4. We have already done this so the CAS servers are redirecting as they should
    5. Create address book policies for each hosted organisation
    6. Move mailboxes and assign ABPs to mailboxes etc.
    7. Decom once all orgs have been migrated

    Now a question I have based on the steps included in the link you sent and the above, it sounds as though as you said in one of your other posts that ABP orgs and ACL hosted orgs can co-exist together. So we could in affect just complete steps 1 - 3 (we have done 4 already) and then only create the ABPs when we plan on migrating customers to Exchange 2010 which would be a gradual process. Does that sound about right?

    On the face of it this would seem that there would only be a very small oppurtunity of time that our customers could potentially view all Address Lists  and that would be between step 1 and 3?

    Thanks again

    Adam

    Wednesday, February 15, 2012 9:23 PM
  • So yes, that all sounds good. If you already have 2010 installed though and have re-secured the GALs and AL's you potentially don't need to do steps 1-4. If it works now, using security groups for tenants the it should continue to work. What you should do is create an ABP for each tenant that contains the same GAL and ALs the ACLs provide access to. You can do that up front or right before you move mailboxes, it really doesn't matter.

    The idea then is, when you move the tenant mailboxes, you clear QBDN, assign the ABP and access should work fine, as the same GAL and ALs in the ABP are the ones they have access to via ACL. ABP=ACL in effect.

    Once all the tenants are moved to 2010, and they all have ABPs assigned you can remove the ACLs as at that time the ABP's are controlling access.

    That make sense?

     
    Wednesday, February 15, 2012 11:46 PM
  • Hey Greg, thanks for sticking with me on this one :)

    So it sounds as though this should be an easy task. We literally have to upgrade our Exchange 2010 RTM servers to SP2. I was thinking that the SP2 install would adversley affect my 2007 tenants using ACL segregation but this would appear not to be the case and it would only affect Exchange 2010 users, which we have none at the moment, except for a test user.

    Also to clarify the SP2 install will work even with the default GAL secured using ACLs? I was under the impression this would fail but I guess the install of Exchange 2010 RTM did what SP2 would do if I was going straight from Exchange 2007 to SP2 (Which is what the whitepaper has been written for)

    So in a nutshell and to summarise I should be able to just install SP2,  create ABPs for each tenant, move the tenants, remove the QBDN and apply the ABP to the tenant mailboxes.

    Does it matter when I move my OAB generation server, currently it sits on Exchange 2007?

    Do you think we should go to SP1 first or straight to SP2?

    Thanks!

    Adam


    • Edited by Adam42 Thursday, February 16, 2012 7:32 PM Typo
    Thursday, February 16, 2012 7:27 PM
  • I won't use the word 'easy', but I'm glad you did. ;-)

    It's the install of the first 2010 server that requires full access to objects like the GAL, so if you already have 2010 in, adding a service pack shouldn't require changing anything (though you need to test, in case I didn't already say that 10 times...).

    Yes to your nutshell summarization. Looks good to me.

    You should move OABgen to 2010, there are lots of bugs fixed and performance improvements in 2010 SP2. For one, in 2007 I bet you build OAB's from AL's, not GAL's correct? We fixed that in 2010 SP2.

    And yes, go straight to SP2. Don't make it harder than it needs to be and make it a multi-step migration.

    • Marked as answer by Adam42 Friday, February 17, 2012 8:11 AM
    Thursday, February 16, 2012 10:16 PM
  • excellent thanks Greg. You have answered  all my concerns in a couple of days, where as trying to cobble up all the different articles on this and understand it all and work out a plan (and have confidence in it) was near impossible and had taken weeks. 

    You have been a HUGE help to us and I thank you!!!!

    Adam

    Friday, February 17, 2012 8:11 AM
  • Glad I could help Adam. Good luck.

    Friday, February 17, 2012 5:44 PM
  • Hey Greg et al

    I thought I would post back with our results from testing. We replicated everything in a vitualised test environment including DC's, Exchange 2007 servers and Exchange 2010 servers. This took a long time in itself. We introduced a new DC into our environment and then moved it onto an isolated HyperV network where we also built our other servers out. We then did a metabase cleanup in both our production and test environments (Exchange 2010 SP2 schema prep would not run until we removed the other production DCs from our test AD). For the Exchange servers we used the /recoverserver switch. We hit lots of issues with this especially when using the /recoverserver switch for DAG members but we managed to find our own fixes for this out of sheer luck. Basicaly we had to clear an attirbute from the DAG member using ADSIEdit, I forget the exact attribute now.

    Anyway once we had our test environment all up and running we decided to migrate a test user to Exchange 2010 SP2 without an ABP created. As per all the articles on the web, we suffered the blank address book issues because of QBDN. We then created an ABP for the test users org and applied it to the mailbox and hey presto everything was as it should be. The only thing we are seeing is that the user seems to have two address lists for the organisation within outlook, not a major issue becuase they are duplicates of each other.

    Any ideas why that could be Greg?

    Other than that everything is fine. We will continue some more tests on some other customers orgs to see if this duplicate address list happens all the time but from where we are at the moment everything is working great and as you expected Greg.

    Many thanks again!!

    Adam 

    Saturday, February 25, 2012 2:07 PM
  • Thanks for the update Adam, and it sounds like you made great progress. Well done.

    I wonder if you are actually seeing a GAL, and an Address List. Do they have the same name? The same filter?

    Know as well that in SP2 you can (and I think should generally) use the GAL as input to the OAB, not an AL. They never used to work, which is why one had to create an AL that contained the same filter as the GAL, so it could be used for OABgen. We don't need that any more.

    So for each tenant I would suggest you create a GAL, an OAB (based on that GAL), a room AL (or a blank room AL if you don't need it), and either room the room AL for the AL part of the ABP, or create AL's for things like contacts, DL's, offices, depts etc.

    Saturday, February 25, 2012 4:44 PM
  • Hi Greg

    I think I need to read up on ABPs :)

    When trying to select the GAL as the input to the OAB when using the EMC I am unable to and the picker only shows all of our offline address lists though.

    I have changed the ABP as per your recommendation and removed Test Company Address List from the AL part of the ABP and used the blank rooms AL. I now only see 1 x Test Company Address List in Outlook so I'm assuming even though the Test Company Address List is not mentioned in the ABP, because it exists as an Address list and the test org has permissions to it, it still shows in the client (As it should). It is definitely not being presented by the ABP though. I guess when we fully migrate each company over to Exchange 2010 and ABP we simply delete the legacy address list as it shouldn't be needed anymore?

    Thanks Greg

    Adam

    Saturday, February 25, 2012 6:11 PM
  • Take a look at http://technet.microsoft.com/en-us/library/hh529948.aspx to get more of a handle on ABP's, in there is an example of how to use a GAL in an OAB, as it's not something you can do in EMC, as you discovered...

    New-OfflineAddressBook -Name "OAB_TAIL" -AddressLists "GAL_TAIL"

    From the description you gave, did you happen name your GAL Test Company Address List? And you are actually seeing that? You shouldn't be seeing an Address List that is not in your ABP. I would check again that the GAL and AL's you have defined are clearly named so you don't confuse them, and are correctly assigned in the ABP.

    Saturday, February 25, 2012 11:15 PM
  • Hey Greg

    Great will take a look.

    No, the GAL was named Test Company Global Address List and the ABP definitely doesn't contain that address list. That said we have just tested with another customer org and that was fine so I dont think it's a big deal maybe my client was a bit confused!

    We want to start making use of Rooms AL's as we haven't used them previously but have been asked by various customers for that functionality in Outlook.  So, we're going to retro fit those and create them for each customer prior to the ABP being created. One thing we have found is that the AL doesn't get populated until the meeting room is actually migrated to Exchange 2010 but I guess that is by design.

    I think we are all straight now, just need to write a script to automate this lot and jobs a good one.

    We use Websitepanel for all our sins so we are just about to test the beta of the latest version in our test environment which now has support for SP2. Its been a frustrating time waiting for this support so I'm hoping its been worth the wait!  

    Thanks again for your pearls of wisdom very much appreciated and I'm sure this thread will help many people.

    Cheers

    Adam

    Sunday, February 26, 2012 12:07 AM
  • Hello, it has been a while since anyone responded to this thread, but I am running in to the issue described by Adam:

    "On the face of it this would seem that there would only be a very small oppurtunity of time that our customers could potentially view all Address Lists  and that would be between step 1 and 3?"

    I have ABP's set up for my organizations, but for some reason Outlook clients (not web clients) are able to list all address lists from every organization. They are not able to view the contents of the lists, but the lists are definitely visible.

    I am also using websitepanel for the setup, but this is a fresh install of SP2, not an upgrade.

    Everything seems to be set up to Microsoft spec, I'm really pulling my hair out here, I have clients ready to go for this box and am just failing horribly on making this thing function!

    Also, my setup is a single box server, all roles on one machine. I have another machine I joined as a member server, and am ready to migrate my boxes should I need to.




    Thursday, August 23, 2012 7:03 PM
  • Keith, a new thread would be a good idea.

    Are you creating the mailbox and applying the ABP before you configure the Outlook profile? Make sure you are. If you create the mailbox with no ABP, then add teh ABP, you might see the issue you are seeing for a short time.

    Also, are you logged in to a machine as a user with a mailbox and no ABP, but are testing against another mailbox with an ABP? If so, Exchange may be getting mixed signals from your creds somehow. Just log in locally to a machine using different username/password than that used by AD/Exchange and try again. I used to see issues logged in locally to my workstation which had the same admin/password combo locally as for the test lab I was using. Windows trys to help, and send creds for the locally logged in user rather than for the mailbox being accessed sometimes. Best just to rule that testing scenario issue out.

    Thursday, August 23, 2012 8:49 PM
  • And and just spotted something - all in one box? Not Exchange and DC on the same box is it? That won't work with ABP's - they won't work at all correctly if Exchange is installed on a DC.
    Thursday, August 23, 2012 8:50 PM
  • So it can't be installed on a DC at all? Do I have to do a complete re-install or do you think I could bring up a members server and move my current mailboxes to it?

    I'm currently using WebSitePanel to create hosted organizations and users, and it appears to set everything correctly, I just keep seeing the lists in the "all address lists."

    I can start a new thread if necessary referencing this one.


    Thursday, August 23, 2012 9:22 PM
  • "So it can't be installed on a DC at all?" - Not if you want ABP's to work.

    When Exchange is installed on a DC, the DC part of the box, not the Address Book Service is answering requests for directory access. The notes for ABP's clearly state they don't work when Exchange is installed on a DC. Sorry.

    What you can do is bring up another Exchange Server, move all the mailboxes to it, and remove Exchange from the first machine. That's the best way to get out of it. It is not supported to DCPROMO a box with Exchange installed on it. Remove Exchange from the DC, not the other way round.

    Thursday, August 23, 2012 10:33 PM
  • Thanks Greg, I already have a member server online, there is a TON of mail to move, but its the weekend, I think I can knock it out.

    Thank you so much.

    Friday, August 24, 2012 2:17 PM
  • Move one or two and test the issue is solved when you connect to them, before you move them all...
    Friday, August 24, 2012 3:26 PM
  • That is the plan so far.

    *edit* - The only thing I'm actually afraid of is that the exchange server is already using DC instead of the Exchange Address Book service. We'll find out!

    Friday, August 24, 2012 5:34 PM
  • Not sure what you mean by that, but as long as the clients are connected to the non-DC Exchange box for directory (via Address Book Service) it should work just fine.
    Friday, August 24, 2012 7:29 PM