Any advice on where I should begin in terms of resources or videos?
Outstanding questions are:
- Should we use Remoteapp or Sessions
- Understanding and deploying TS gateway
- How does SAV work with individual sessions (viewing them as virtual desktops)
- How should we setup our profiles for osts?
- Would it be ok to have this new server running terminal services as our BDC?
- Can we use remote apps on xp machines, heard only for Windows 7, need to verify.
I don't have a response for the "resources and videos" bit other than to direct you toward Microsoft's web site and suggest you read documentation there.
To speak to your questions, though:
Generally the RemoteApp functionality is used to provide the "look and feel" of a native application running inside a user's traditional "thick client" Windows session. I've used the RemoteApp functionality to, for example, deliver a "shared file database" application to clients over a WAN. The application would not have been able to function over a WAN because of its "database" "architecture" but, as using the RemoteApp functionality allowed the application to appear to remote users as a native application on their existing Windows client computer.
If you're looking at delivering one or more specific applications to users with existing Windows clients then using the RemoteApp might be the way to go. If you're looking at using thin-client type devices or don't want users to have any "local computer" experience then RemoteApp probably isn't for you.
Microsoft has documentation on the TS Gateway functionality that does pretty well. TS Gateway is, basically, an application to proxy the Remote Desktop / TS protocol over HTTPS. This allows your users to connect to TS sessions (either hosted by a dedicated server or, as is the case with Windows Small Business Server, for example, their dedicated desktop PCs) via an untrusted public network. Most challenges relating to deployment of TS Gateway, in my experience, have come from not understanding the PKI requirements. Using self-signed certificates with TS Gateway w/o deploying your CA root certificate to all the clients, for example, is a recipe for frustration.
I'll fill this in if you can tell me what you mean by "SAV"? This isn't an acronym I'm familiar with in reference to Terminal Services.
It sounds like you're talking about delivering Microsoft Outlook via Terminal Services and you want to know if you should configure the users' MAPI profiles to use Cached Exchange Mode. If that's not accurate, let me know.
Using Cached Exchange Mode (OST files) is generally a good idea for Exchange Server performance reasons, provided the user's OST isn't going to have to be rebuilt over and over again. The OST is stored in the user's "Local" portion of their user profile. In the case of a Terminal Services environment if the user is connecting to one of many Terminal Server computers in a "farm" then the user may end up receiving a different local portion of their profile on every logon and you may end up causing a lot of excess traffic to Exchange rebuilding / updating OST files. If your users are going to be connecting to the same Terminal Server computer for each session then using Cached Exchange Mode shouldn't present a problem since the local portion of the user's profile will persist between logons.
There are no "BDC" computers in Active Directory. You really mean, I think, "Should we make the Terminal Server computer a domain controller?" In generally you should not. Domain Controller computers perform a very security-critical function, and allowing general users to execute code on them opens you up to risk. Sure-- if the OS was bug-free there wouldn't be any risk at all. No software is bug-free, though, and it pays to employ a defense-in-depth strategy that includes not allowing users to execute arbitrary code on Domain Controller computers.
Provided your Windows XP computers have the version of the Terminal Services client loaded with Windows XP Service Pack 2 or newer (and you really should be running SP3 anyway) you'll have no trouble using the RemoteApp on Windows XP clients.
I would just start with the Technet page. The Remote Desktop Services, the new name for the Terminal Services role, homepage walks you through assessing your situation, planning your setup, deploying your solution, and troubleshooting should any issues arise. Towards the bottom of the page is also the featured technical resource on deploying a Remote Desktop Gateway, formally known as the TS gateway. You may also want to check out the Remote Desktop Services Best Practice Analyzer page.
Use what you want to use based on your requirements. Without any details we can't give you a recommendation.
It is an application-level proxy. Perhaps you need to be more specific about what you need to know in a seperate question?
A terminal server should NOT be on a domain controller. You could screw up the domain, there is the potential of a user being able to perform attacks against your DC. Instead of worrying about remote attacks, you have to worry about privilege escalation attacks. For terminal server to operate security settings are lowered.
FYI: there are no BDCs in a 2000+ domain. Every DC is pretty much equal.
From: http://technet.microsoft.com/en-us/library/cc753844(WS.10).aspx
To access RemoteApp programs that are deployed as .rdp files or as Windows Installer packages, the client computer must be running Remote Desktop Connection (RDC) 6.0 or RDC 6.1...
The RDC 6.0 software is available for use on Windows XP with SP2, Windows Server 2003 with SP1, and Windows Server 2003 with SP2.
???