We help IT Professionals succeed at work.

Exchange 2010 ActiveSync Issue

JamiBenson1979
JamiBenson1979 used Ask the Experts™
on
Hello All! I am fairly new to being a exchange admin and I'm having a odd issue. When I started work on Tuesday I added myself on both Exchange and in the Domain. I can receive and send email. I can do everything I need so I haven't screwed things up too horribly...yet. Well the next day I go and type in my name in the Global Address Book and I'm not in there. I figure that I just need to update the GAL. I use the shell command and the next day, I'm still not in there. i started thinking today and my email also won't sync with my phone. I start doing some research and I come across an error in my event log that has the following:

Event ID 1053 Active Sync

I do some research on the error and it seems easy to fix it. I'm gonna feel like an idiot asking this but when I click on my user object I can't find the security tab. I have attached a screen shot. Am I missing something?

I am using Windows Server 2008  and Exchange 2010

My boss has never touched access either so I'm kind of flying blind. Thanks for any help you can give the noob :)  properties-screen-shot.docx
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®

Commented:
Hi,

Follow below mentioned link steps to resolve the subject issue.

http://blog.nick.mackechnie.co.nz/post/2009/11/20/Exchange-2010-Active-Sync-Issue.aspx

Hope this will help you.

Have a nice day.....

Author

Commented:
Thanks for the response. I had already read the link. If you look at my screen shot you will see I don't have a security tab. That is the issue. I read that exact post to solve my issue, but no security tab so I can't do that solution.

Any other thoughts?

Jami
Top Expert 2011
Commented:
To enable the security tab within active directory users and computers you need to open the view menu in aduc and choose advanced features. Now you must be able to see the security tab.
Site Reliability Engineer
Most Valuable Expert 2011
Commented:

Did you add your personal account as a Domain Admin (or to the domain 'Administrators' or some other 'default' AD group)?

If so, you can 'hack' it into working by enabling inheritance as previously described, but the real reason is due to some special security precautions which are added when using a default group. The adminSDHolder attribute in Active Directory stores a series of permissions which are applied to members of those protected groups on a periodic basis. Even if you do enable inheritance, it will be disabled in a subsequent update of your account permissions. This is a security feature designed to protect members of protected accounts.

The issue arises out of the fact the 'Exchange Trusted Subsystem' security principal is not present in the adminSDHolder. All Exchange operations take place under that security principal, and for normal accounts, it is inherited through the domain tree. When inheritance is disabled by SDProp, the permissions present on that protected account do not include Exchange Trusted Subsystem, thus the reason for the error you see.

There is a good reason for this - best practice dictates (and for a very good reason) that standard user accounts should not be Domain Admins or members of any of the other protected groups. You should ideally remove all those permissions from your account and then either use RunAs to launch tools with a privileged account where required, or delegate your account permissions (in AD, for example).

Even if you do reverse those permissions, you will need to tweak your account to prevent the permissions from continually being overwritten: http://theessentialexchange.com/blogs/michael/archive/2008/10/22/admincount-adminsdholder-sdprop-and-you.aspx

-Matt

Author

Commented:
Thanks for your suggestions. I will give it a try when I get back in on Monday!

Thanks for all that info Matt! I really appreciate it. I am a Domain Admin. Should I take myself out of that group and all?

Again thanks for all the knowledge. I'm so new at this and it's lovely to have this resource. Y'all are great!

Jami
tigermattSite Reliability Engineer
Most Valuable Expert 2011
Commented:
Yes, you shouldn't put your standard account which you use on a daily basis into any of the 'protected groups' (most of the ones which exist by default). That includes 'Domain Admins', 'Enterprise Admins', 'Administrators', 'Print Operators', 'Backup Operators' etc.

Anything which, by default, grants elevated privileges to a system or service is going to be protected by the adminSDHolder/SDProp service due to the security ramifications. That will not only stop activesync registering against your account, it also poses a security risk.

The best practice is to use a standard account which isn't a member of any special groups for your day to day tasks. You can then either delegate permissions to that account (create a custom security group, delegate permissions to that group, then make yourself a member of the group), or right-click programs and use 'Run as a different user' in order to launch things with elevated permissions, where necessary.

For example, if you needed to manage a printer, rather than use Print Operators, add a new security group to the printer, set the permissions on the printer which are assigned to that group as reqired, and finally, make yourself a member of that group in Active Directory. You aren't giving out 'default' permissions to the account you use on a daily basis -- when logged in to a workstation all day, that increases the risk of your network being compromised.

The latter point applies especially to 'Domain Admin' groups. DAs can do anything to the domain, and in multi-domain forests, Enterprise Admins have even more ability to cause damage. DA/EA group membership should be strictly audited and only ever used when absolutely required -- any other time, you can delegate control over tasks like AD to your personal account, alleviating the need to use a DA account.

There are also many applications which will request DA credentials to bind to active directory for some purpose. The developers rarely, if ever, need DA access. Before granting such access, you should always consider the ramifications. A DA can irreversibly damage the domain. By providing such credentials to an application, you are trusting that application's security system with your entire domain - your entire company's IT asset, including email. If that app isn't secure and gets hacked, you can mitigate risk if the AD account it uses only has the required permissions.

If you remove yourself from those groups, you need to reset the adminCount property on your user account to reverse the effects of SDProp, as described in http://theessentialexchange.com/blogs/michael/archive/2008/10/22/admincount-adminsdholder-sdprop-and-you.aspx. Removing the group membership isn't enough.

Glad to be of assistance!

-Matt
tigermattSite Reliability Engineer
Most Valuable Expert 2011

Commented:

I just realised that blog post doesn't discuss actually reversing those changes in as much detail as I thought (but it covers the technical background of adminSDHolder/SDProp very well).

If you need info about reversing the changes caused by being in a protected group, let me know. However, if you aren't comfortable using ADSIEdit to edit low-lying AD attributes, you might be better placed exporting your mailbox, deleting your account and creating another, not adding it to any protected groups this time.

-Matt

Author

Commented:
So I can now sync my email to my phone. That's awesome thanks for your answers on those. My issue now is I still can't see myself in the GAL. What's the best method to rectify this? Should I use the script to update the address book or do I need to do something with the OAB since we used cached exchange mode? As a note if I don't use cached exchange mode I do see myself.

Thanks for all your help so far!

Jami
tigermattSite Reliability Engineer
Most Valuable Expert 2011
Commented:
The 'GAL' you see in Outlook when in cached mode is in fact the OAB, and it can take some time to catch up. Exchange generates the OAB on a schedule and makes it available for Outlook clients to download, either via Public Folder Distribution or Web Distribution (the Exchange configuration will depend on which method is in use, but for info, Outlook 2003 and previous will only use Public Folder distribution as they do not support web-based distribution).

There can be a lag time of 24 to 48 hours between a user being added and their account eventually appearing in Outlook. You have rightly confirmed you are in place by disabling Cached Mode, since disabling will cause a live copy of the GAL to be used. A similar test is to use OWA.

If you did the delete/re-create to get around the adminCount issue, then it is simply a case of waiting for the OAB to rebuild and have Outlook download it. That would explain why your new account is yet to appear. Forcing an OAB rebuild on the server isn't going to cause your account to appear on all the user workstations; each user's Outlook instance still has to go and fetch the rebuilt OAB, so it's best to just let Exchange handle the process itself.

-Matt

Author

Commented:
Thanks for the solutions all. Ronny and Matt were exceptionally helpful! I have some exchange books now so hopefully I'll get up to speed on this stuff real soon.

Thanks again!


Jami