Endpoint Security Complete

 Hi guys,

We recently moved to MDM 7.2 SP2.1, after this upgrade we noticed that our devices stopped recieving e-mail. Upon investigation I found that the account name being used in the e-mail profile was set to "domain.com.au\username" instead of just the username.

Our EAS profile is generic so I checked SQL and sure enough, all the values in the UserID field in Inv_Symantec_Mobile_Device were set to "domain.com.au\username", whereas previously this was just the enrolled username. As the devices only send the userid field to MDM upon enrollment, I'm thinking this was some process of the upgrade.

I'm assuming this was done by design and the userid being populated that way is for a reason, but that doesn't work for us for several reasons, so I've put it back the way it was.

I did a search of connect and didn't see this already posted. Hopefully this value change has only affected the way we implimented MDM, but if not then I hope this SQL query comes in handy. This query will trim the domain and backslash from the UserId field. Just change the value '21' to the number of characters you need to trim from the left.

SQL Removed until I get a better understanding of why this was changed so the domain info is included in that field.

I just re-enrolled my device and the UserID field has a domain in front of it again. This is really not suitable.

I've used the token in the EAS profile so it only sends the username, but I rely on that field for other stuff. If someone's at least able to tell me the reasoning for populating UserID with the domain field as well, that might help.

I saw this too when I upgraded. This didn't make my life alot easier. To get my mail working I had to remove the domain name in the mail profile so it could use the username with domain name insted. I can see your point if you changed your domain name after the devices was enrolled.

This change also f**ked up my filters that was based on user name in the domain.

I had to rewrite all my filter in raw-sql to make it work.

Thanks alot

In the EAS configuration, you can use tokens.  Are you using these?

{userid} pulls from Device.UserId field and replaces
{user} pulls from Device.UserId field, to the right of \ (if present), and replaces
{email} pulls from the Device.Email field and replaces

This depends on how users enrolled (e-mail address vs. URL; whether they enroll as DOMAIN\Username or Username or user.q.name@company.com).  If your users enrolled as company\username, then your EAS profile should be configured thus:

Server: owa.whatever.com
Domain: whatdc
User: {user}
E-mail address: {user}@whatever.com

This yields:
Server: owa.whatever.com
User: mclemson
E-mail address: mclemson@whatever.com

If you create and test an EAS profile, does this yield the expected result, based on how your users enroll and how your Exchange ActiveSync is configured?

Hi Mike, Not sure if that suggestion was for me or Madd0x, but in my case at least I'm already using the token (as I posted above), I'm also now using the username value in Mobile_common for my reports and rules now (until Symantec decide they want to add the user's A/S/L or something in that field), but that's not really the point. I'm trying to find a nice way of saying this (and I've re-typed it a bunch of times), but Symantec need to stop making changes like this with so little regard on how it affects existing environments. It is NOT ok for our userbase to be affected by something this stupid. Development got back to me and state the change was made as environments are often cross-domain (ours certainly is), however there's a domain field ALREADY in Symantec_Mobile_Device that is unused, that information should have gone there.

There's no excuse for bugs, but if bugs are unacceptable, you should install in a test environment first.  An alternative is to install in production and hope the issues are detected in post-install testing outside of business hours and can be resolved by the time business starts the next morning (not preferred).

Yes, Symantec release notes for SMM need to improve in quality and thoroughness.  As a partner we've been surprised as well and have had to find out by installing in test and attempting to notice changes.