we have two front-end exchange 2003 servers (i.e. front1 and front2). how can we restrict user1 to only being able to use front1 and restrict user2 to front2? specifically, we want to restrict their rpc-over-http access to a specific front end server to connect their outlook client or to restrict their active sync connection when connecting their entourage, iphone, ipad or droid. whether or not we restrict OWA for specific users on specific front end server is okay with me. the focal point is the connection they use for outlook, entourage, iphone, ipad or droid. thanks. ~m

Whats the goal for this requirement? What problem are you trying to solve?

Previously we had all our user's devices/clients connected to a single front end 2003. the front end server was crashing at least once if not twice a week (no joke). since then we added a second front end 2003 server, and moved off most of the "general" users onto the 2nd front end, while keeping the "executives" on the 1st front end...i am happy to say that we have been crashed free since we made the transition over two weeks ago. now the goal is to prevent unauthorized users from connecting to the wrong front end which is the reason we were in this mess to begin with. we had users that are too smart for their own good. they looked at the rpc-over-http settings or active sync settings on their devices, and proceeded to copy it to their other devices and also spread the word to other users. next thing you know we had all these users and their multiple devices connecting the same way as our executives. i noticed in AD that you can disable certain exchange functions, *but* i do not want to *completely* disable the function for the user to *all* my front end servers. i just want to be able to disable it for a specific server. not sure if this can be done. Hope that makes sense. Thanks for the help. ~m

input

input

There is no practical friendly way to assign the front end. You can do restrictions whether by local local denials or some other methods but these are not friendly; user hits the frone end gets denied tries again and may hit the other one. Again not friendly. Other option is to publish 2 different URLs which again is not friendly. You will never hear of any orgs doing tiered services with frontend or CAS, all CAS\frontends should be equal in performance, reliability and patches. So in the end the issue just needs to be fixed.James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

We publish two different urls now: front1.domain.com and front2.domain.com. front1 is the existing url that everyone knew about, while front2 is the new one that I switched most general users to. I can change the url for front1, but if that info falls into the wrong hand, then we are back again to where we were a couple weeks ago. I want to be able to restrict based on permissions. i am not too concerned about the "friendliness" that it has to be done. I went to Exchange Manager > Administrative Groups > first administrative group > Servers > highlight front1 > right click choose Properties > Security tab > chose the user account I want to restrict and set all permissions to Deny...Thinking this will solve my problem, but sadly it did nothing...I was still able to logon to OWA and use RPC-HTTP and Active Sync connections. Suggestions? Thx, ~m

Fire up local security policy from admin tools on the front end, local policies, user rights assignments "deny access to this computer from the network" and add the users or groups. When you do this the user will not be able to log into OWA and keep getting prompted. Keep in mind these are workarounds, there may be other work arounds such as doing NTFS permission denies on bin directories on the specific front end etc. This means you're not "non supported" work arounds. Make sure you test full functionality before implementing. James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

James, That worked fine. As you stated, "not friendly", but effective. Thanks again. ~m

great share, Thanks.

great share, Thanks.