Installation of Microsoft Online Desktop Setup on Remote Desktop (Terminal) Servers
-
miércoles, 26 de octubre de 2011 11:53Our current BPOS customers use Windows 2008 Remote Desktop Servers (RDS) to provide their day to day desktops. The Sign In Tool works well in this kind of infrastructure. Are their any considerations for "installing" the Microsoft Online Desktop Setup tool on a Remote Desktop Server in preparation for the transition to Office 365? A guide on how to get this going in an RDS environment would be great.
PaulK- Editado myGenii miércoles, 26 de octubre de 2011 11:54
Todas las respuestas
-
lunes, 07 de noviembre de 2011 15:42Am I posting this in the wrong forum? Please point me in the right direction. How does Office 365 work on a Remote Desktop Server?
PaulK -
sábado, 19 de noviembre de 2011 1:01
Hi Paul, sorry you had to wait so long!! Desktop Setup is not supported in RDP environments and as such you will need to push out manual updates to your users RDS sessions. Once you can get these updates pushed out, the OS, Browser and Office 365 applications will be up to date and can use Online Services without issue.
In BPOS there was an isue with Outlook NOT supporting a virtual environment as there was no way to use Cached Mode .ost files in this configuration. I believe Outlook 2010 has resolved this issue, so your clients should be able to use Outlook in the RDS session environments.
Manual Updates: http://onlinehelp.microsoft.com/en-us/Office365-enterprises/ff637585.aspx
HTH
Ryan J. Phillips- Propuesto como respuesta Daniel Trautman martes, 13 de diciembre de 2011 3:34
-
lunes, 23 de enero de 2012 18:23
Thanks Ryan and Daniel,
I am hoping that we can wangle a little more guidance out of you with repect to the specific steps and expectations during the migration. For my purposes, we only need to worry about Outlook/Exchange.
As of today, A Remote Desktop user logs in to the server and and the BPOS Sign in Tool pops up and gets folks logged in. When they open Outlook, it just works.
When the tranistion has begun:
- When should we disable the BPOS Sign in Tool (During the migration or only after it has been completed)?
- When the migration has been completed and the sign in tool has been disabled, what will we have to to to Outlook to enable it to connect to Office 365? Do we need to manually set up a new profile?
- Will we have to manually delete the Profile that BPOS was using?
Thanks in advance and I hope that makes some sense.
PaulK -
martes, 31 de enero de 2012 17:30
Since no response from the transition team was forthcoming, I'll relate my experience. It is a shame that we couldn't get "official" guidance and had to go through the transition on our own. Note: the behavior described is for a user logging in to a Remote Desktop Server on Windows 2008 R2 and only talks about Outlook/Exchange migrating from BPOS to Office 365.
The first thing to note is that we didn't install anything on the Remote Desktop Server. We didn't install any of the Office Updates, the Sign In Assistant, or anything else. Since we couldn't get any up front help, we figured we'd cross our fingers and then try to backfill updates etc. as required.
Here's waht happend in our specific case. The morning after the migration, folks fired up their desktops and the BPOS Sign-in-Tool ran as usual. We opened Outlook and it prompted for a user name and password. We fed it the appropriate credentials, checked the box that says "remember my password" and it connected. The user immediately got the "The Exchange Administrator has made a change that requires you quit and restart Outlook." error message. When we quit and restarted Outlook it again asked for the user name and password and we again entered the appropriate credentials and again checked the box that says "remember my password". Outlook would now open and close without a password nag. At this point, we opened the already running BPOS Sign-in-Tool and under the Options Tab, deselected the "automatically sign me in" and "automatically start when Windows starts" check boxes. We then clicked on "Sign Out" and the BPOS Sign-in-Tool closed, never to be heard from again.
I hope that helps and I hope the Transition Team can eventually answer these and other questions:
- Should the Sign-in-Assistant be installed on a Remote Desktop Server? If so, when and how? If not, what won't work?
- Does it make any difference if you are using the a Federated AD? Do you need the Sign-In-Assistant in this case or not?
- Which of the "manually install desktop updates" are really necessary in a Remote Desktop Environment?
PaulK -
miércoles, 01 de febrero de 2012 19:21
PaulK,
We have our transition scheduled for this Friday and I spent 4 days on the phone with "Bob" in support to have them tell me it is not supported. Thanks for your instructions I will see if they will work for us and post the results back to you.
Makes me want to move to Google.
Jason
-
jueves, 02 de febrero de 2012 3:14
Hi Paul, I see you are a Partner and start each of your Posts "Since no response from the transition team was forthcoming, I'll relate my experience. it is a shame that we couldn't get "official" guidance and had to go through the transition on our own".
Let me ask a few question:
Being a Partner, you do know about the following Transition Resources that are dedicated to Transitions, correct?
- Transitions Website: http://www.microsoft.com/online/transition-center_before.aspx
- Admin Transitions Guide: http://g.microsoftonline.com/0rmcm00en-us/5004
- Before/During/After Transitions Videos: Bottom of the Transitions Website webpage
- Transition Help Desk Support Team (dedicated to Transitions Support):
(800) 865-9408
- Ask for the Transitions Help Desk team!
So to your questions:
- Should the Sign-in-Assistant be installed on a Remote Desktop Server? If so, when and how? If not, what won't work?
Ryan - The SIA should be installed on a per user basis, although the MSOID LSA Authentication Provider is MACHINE specific. So if using RDS, installing onto the host machine would not give you anything, but should be installed for each user RDS session.
Note - The SIA installs the MSOID LSA Security package and is used in specific situations. It is provided to support Rich Applications, such as Outlook, CRM Outlook Add-In and the Lync 2010 client. If using an Online Identity, the LSA MSOID security package is used to present the OrgID formatted credentials. If using a Federated Identity it pre-fetches an ADFS auth token and is used when accessing online services. So in federation, SIA determines the user is a Federated user and get some pre-ADFS auth tokens for use. if Online identity, it uses the OrgID Security package to submit creds in the proper format.
- Does it make any difference if you are using the a Federated AD? Do you need the Sign-In-Assistant in this case or not?
Ryan - Addressed this above, as the SIA is helpful whether using Online Identity or Federated Identity. Since we don't know why auth method will be used, the SIA provides a new security package and ability to get a pre-auth ADFS token for use when accessing online services as a federated identity.
- Which of the "manually install desktop updates" are really necessary in a Remote Desktop Environment?
Ryan - None of the updates are specific to RDS, only to get the Browser, OS and Office Apps with the proper updates. So if you have an image that is used in the RDS environment, you can run Desktop Setup once on one of these machines, determine which items that need to be installed and then manually roll these out. As you have already seen end-users need Admin rights to install these patches and since the Desktop Setup is an .exe, which cannot be rolled out with elevated privileges, as with an AD GPO, admins are rolling up these individual .msi updates/patches into an AD GPO and pushing these out with elevated privileges, getting these properly installed.
Hope this helps Paul, sorry for the late response, I'm trying to address each and every question out here :-)
Transitions Community Lead ...Ryan J. Phillips- Propuesto como respuesta Ryanph [MSFT] jueves, 02 de febrero de 2012 3:59
- Marcado como respuesta myGenii miércoles, 08 de febrero de 2012 15:04
-
jueves, 02 de febrero de 2012 3:55
Hi Paul:
When the transition has begun:
- When should we disable the BPOS Sign in Tool (During the migration or only after it has been completed)?
Ryan - After, for sure after. This is so the SIC can pick up the fact that the user has been moved and it will remove the AutoD Outlook registry entries that the SIC wrote, PreferLocalXML = autodiscover.xml which points to BPOS EXO. Once that is gone, SIC is configured to no longer automatically run at logon. once this is done you will of course want to have autodiscover.domain.co pointing to autodiscover.outlook.com, so Outlook can chase down the correct Messaging environment, connect, authenticate and RE-establish a connection with their old MBX. because the MBX is the same and the .ost has the MBX GUID referenced, it does NOT have to sync the .ost, saving tons of bandwidth and time...whew.
- When the migration has been completed and the sign in tool has been disabled, what will we have to reconfigure Outlook to enable it to connect to Office 365? Do we need to manually set up a new profile?
Ryan - Nothing OTHER than creating the autodiscover.domain.com DNS record that points to autodiscover.domain.com. Once done Outlook will ditch the PreferLocalXML, as that file and reference is gone, find the DNS record and chase down EXO365, connect, authenticate and reestablish connection! You don't need to create a new profile. use the same as the old .ost file can be used, which will match the O365 MBX and you are good. you could create a new profile, but will have to resynch the .ost which cool take a while :-(
- Will we have to manually delete the Profile that BPOS was using?
Ryan - The uninstall does remove some of the files, but I believe some of the SIC login profile information is left behind and can be removed without issue. It is not much content, a few files used by the SIC and can be removed without issue.
HTH
Transitions Community Lead ...Ryan J. Phillips -
jueves, 02 de febrero de 2012 19:03
Ryan,
Thanks for your response. I called the response team and I have had a case open for going on 5 days now and have not been able to get as much information as you have provided today. I agree with Paul and I think there should be a better response from Mircrosoft on the configuration. Thanks. for your reply I hope it will help with my transition this weekend.
Jason
-
domingo, 12 de febrero de 2012 4:46
Hi Jason, I hope you don't mind, I'm taking your response along with PaulK's from above, a Partner who is NONE too pleased with the responses given in this Forum. I will make sure that our transition teams get this information distributed out to everyone, so they can better articulate our support stance on this.
The problem is that they are probably not RDS experts and it is not clear to them the restrictions and issues that Virtualized environments can have on software.
Ultimately it is not an issue of the Online Services and RDS it is the underlying applications, such as Outlook that may have issues. In Outlook 2007 it did not support running in Cached Mode (.ost), therefore you had to run in Online Mode, which was not technically supported against BPOS EXO but it did work, but you needed a good connection, otherwise the experience was not good. In Outlook 2010 it does now support running in cached mode in a virtualized environment. i have not heard any problems with the Lync client, so in terms of technical aspects I don't know if there are any problems with this configuration.
Let me make some internal queries and see if I can get an OFFICIAL answer as to whether we support the Office applications in an RDS environment for O365. Again I know that Outlook 2007 has issues, while Outlook 2010 works just fine.
Unless I am tracking on the wrong question here? if so, can you please re-post exactly what you are looking to have answered and I'll get right on it :-)
Thanks Jason!
Transitions Community Lead ...Ryan J. Phillips

