Running Microsoft Management console (MMC) as a standard user without Admin privileges

We had an interesting question posed to us about allowing standard users to launch and work with the admin tools provided by the MMC, and whether the MMC requires elevated privileges.

We found some interesting thing upon testing, firstly no MMC doesn’t require elevated privileges to run some no UAC prompt will pop for the standard user and they will be able to launch and work the tool although will not be able to make changes without extra permissions, we are just talking about an account that is just part of domain users group.

An UAC consent prompt will be shown if trying to open mmc.exe while logged in with an account that has admin privileges.

We also found that if the standard user was a part of the “Group Policy Creator Owners” and they tried launch mmc.exe then they would be presented with access denied and UAC asking for admin credentials.



CRM 4.0 Email Router not tracking email

We worked on a CRM 4.0 environment, where the Email router was not tracking incoming email, it turn out is was a problem with the configuration, we were also getting incoming status failure message.

To fix the Tracking issue the following settings were changed to correct the configuration:

  1. Open CRM 4.0 in the browser, click on the Tools button in the top menu.
  2. Then click on Options in the dropdown.
  3. Now click on Email tab.
  4. The “Track” setting was change from “E-mail message in response to CRM e-mail” to “All e-mail messages”

The following setting also changed:

  1. Open CRM 4.0 in the browser, click on the Settings button in the left menu.
  2. Then click on Business Management menu item.
  3. Now click on Queues on the right.
  4. Double Click on the Queue used to for tracking.
  5. Change the setting for “Convert to email activities” option  from “E-mail message in response to CRM e-mail” to “All email messages”

After setting the above two setting the tracking started working.

To resolve the incoming status failure the following commands were run to set the correct permission for access and impersonation:

  1. The following to allow CRM to access the user mailbox:
    Add-MailboxPermission “Mailbox” -User “username” -AccessRights FullAccess
  2. The following to allow CRM to impersonate the users mailbox:
    Add-ADPermission -Identity “Mailbox” -User “username” -extendedRight ms-Exch-EPI-May-Impersonate
  3. Finally the following to allow CRM to impersonate the exchange CAS server:
    Add-ADPermission -Identity “ClientAccessServer” -User “username” -ExtendedRights ms-Exch-EPI-Impersonation



App-V Client Authentication Problem when you Install Live Essentials or Office 365 client components on the same windows client

When you install Live Essentials or Office 365 Single Sign in Assistant they install Security Support Providers of their own, “liveSSP” and “msoidSSP” respectively. These value are added to the “Security Packages” key in: “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\”

Removing the “liveSSP” and/or the “msoidSSP” entry from the security packages key does temporary fix the problem, but if an update to office 365 or live essentials is applied then the SSP values are written back to the Security Package key and the issue occurs all over again.

Msoidssp is a SSP used to align the SSPI interface with the client so that the client can connect with the server in the secure channel, more information about this SSP in the following link:

In office 365, it’s already using the secure channel, msoidSSP was a second secure channel from the windows 7 client for it to drop back on to like a safety net if the it was unable to secure communicate using the normal method. Removing the registry should not impact the usage of office 365 services as long as it is able to communicate successfully without the need to drop back to the second SSP.

The bug fix should be available in App-V client 4.6 SP2.

App-V 4.6 SP2 Release notes, please read before updating to SP2:

Download Link: