AzureAD: The user or administrator has not consented to use the application with ID ”

I have recently been working on a Multi-tenant Web Application that makes use of delegated permissions.

After developing the application for a while I found that I needed to add another delegated permission to the application which I did using the normal methods.

However, when I tried to make use of the new delegated permission with the test user I had been using for a while I didn’t get prompted for the application’s consent as I did originally and I ran into the error:

The user or administrator has not consented to use the application with ID '<App ID>'

However, when I used a completely new user who hadn’t used the web application before, there were no issues at all. This led me to believe that there was a problem with the new delegated permission not applying to my normal test user, I had expected a new prompt for consent when I went to access the application given that the permissions had changed, however this didn’t happen and therefore led me to believe that the issue was related to this change and me never granting the consent for the additional permissions.

I scoured the internet for any documented help with this but I wasn’t able to find anything, certainly not documented.

I was able to solve the issue in the end by revoking the consent for the test user and re-logging into the application and therefore re-consenting but with the new permissions. This can be done as follows:

  1. Navigate to https://myapps.microsoft.com
  2. Click on the properties for the App and click on remove
  3. Log out of the application or open a new in-private browser session and you will get prompted for consent
  4. Delegated permissions will now work.
Advertisements

Windows Azure: ACLs apply to ALL traffic on the local port

Its not very clear fromt he documentation that adding an ACL also affects internal virtual network communications as well as external endpoint access on the port defined.

For Example:

If you have two machines in different services connected via the same virtual network and are using the internal subnet IP for communication, the ACL will be applied to the traffic on the internal IP aswell as the external IP/Endpoint you apply it to, even if your not accessing the port via the external IP/endpoint.

Therefore, ensure you allow access for your virtual network subnets if you do plan to allow communication internally as this has caught me out on two occasions now.

I’m sure there’s a good reason as to why the ACL is applied to internal traffic too, but given you don’t need an endpoint defined for internal communication and the ACL is applied to the endpoint it is a little confusing.

Note: This also applies to Site-to-Site links (And assume Point-to-Site, although have not tested)

Exchange 2013 – Content Indexing during Migration

After the correct updates have finally been released last week (Exchange 2010 SP3 and Exchange 2013 CU1) it was time to get some Guinea Pigs… sorry, “Test Users” migrated over to Exchange 2013.

Some of the very small mailboxes were fine, but when it came to a real users mailbox the progressed appeared awfully slow. After taking a look at the log, I found it was full of:

The job is currently stalled due to ‘Content Indexing’ lagging behind on resource ‘CiAgeOfLastNotification()’

The message is a little misleading as it appeared that the content indexing wasn’t lagging at all, it was plain not working and showing as failed for the mailbox database.

After many reboots and diagnostics I still couldn’t figure this out, so I turned to google and finally after digging quite a bit I found the answer.

Please be aware that you will find this issue is most commonly talked about in reference to DAG groups replicating, but its a similar issue with migrations.

The answer was thanks to Bright Murewanhema on the technet forums (link), who contacted Microsoft Support for the resolution.

It appears that there’s a bug in Exchange 2013 RTM (which isn’t fixed by CU1 it appears) which causes the Exchange 2013 to not setup all the groups needed in Active Directory. The one in particular is called “ContentSubmitters”. You need to:

  1. Create the group yourself manually in Active Directory (I created in the existing exchange groups OU)
  2. Change the security on the group (not the members!) to allow “Administrators” and “NetworkService” accounts “Full Control”.
  3. Restart “Microsoft Exchange Search” on your mailbox server(s)
  4. Restart “Microsoft Exchange Search Host Controller” on your mailbox server(s)

After you have completed the above you should notice the mailbox databases content index status change to “Healthy” instead of “Failed”, and your migrations will start to transfer at a much more bearable rate.

SharePoint 2010: Classic to Claims Migration Gotcha

I’ve been migrating classic mode SharePoint 2010 sites to claims sites for a while now, so much that I even have a script to do it for me. However, for some reason I have never come across the problem I encountered today.

The documentation on converting a classic mode web application to a claims based application I though was pretty solid on technet. Today I came across a strange issue where the site collection administrator was getting access denied in odd locations… or locations I thought were odd because SharePoint hadn’t security trimmed the links as I thought it would if access really was denied.

Turns out there is a small paragraph at the very bottom of the article which essentially points out “don’t forget to update your super user/reader properties!”… which I did! Not sure why I haven’t come across this until now but hope this helps others with the same issue.

The below PowerShell should help you out in fixing the issue:

$wa = Get-SPWebApplication -Identity <web app url>
$wa.Properties[" portalsuperuseraccount"] = "i:0#.w|<super user account in domainlogin format>" 
$wa.Properties["portalsuperreaderaccount"] = "i:0#.w|<super reader account in domainlogin format"
$wa.Update()

SharePoint 2010 Development Machine with Office 2013

If your trying to setup or change the configuration of SharePoint on a development machines which has Office 2013 install you may encounter some strange errors relating to types such as:

Failed to call GetTypes on assembly Microsoft.Office.InfoPath.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c. Could not load file or assembly ‘Microsoft.Office.InfoPath, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’ or one of its dependencies. The system cannot find the file specified.

This is related to the way in which SharePoint is loading certain assemblies and struggles with the new assembly for InfoPath. Thanks to Hermanote for the workaround which is to remove the InfoPath feature from office only, and the error goes away.

SharePoint 2010 State Service Database

I recently found a small bug in the SharePoint 2010 PowerShell comlets for creating the state service database using “New-SPStateServiceDatabase”.

You will receive the rather unhelpful error message “Operation is not valid due to the current state of the object”. I believe this is a generic WCF error as that’s all I was able to find when researching what may cause the problem. However, it later transpired that this was because I was trying to use a database alias (or potentially database server) which SharePoint isn’t currently aware of, as using the alias (or database server) that was used for the initial farm setup didn’t result in the same issue.

Its taken me a while to find this one as the state service isn’t usually one of the first service applications I configure, so it appears most of the other service application creation cmdlets don’t mind registering a new database host, but for some reason this one does!

If you use sql alias (as a best practice you should) and have a different alias for service applications, I would advise creating another service application before creating the state service database in order to make sure SharePoint is aware of the alias/dbserver.

Lync 2013 – Front End Server ‘Starting’

Upgrading Lync to 2013 recently I came across a problem where the front end service simply wouldn’t start but would get stuck in “Starting” mode.

I spent quite a bit of time trying to figure out what the problem was and got caught up in some false information on the technet forums that it was related to Server 2012. In fact the problem was fairly simple if you know whats going on under the hood.

When the server firsts starts it synchronises user information from active directory, but here’s the kicker, if you have multiple domains in your active directory forest regardless of where the server lies, it will try to get user information from the other domains, if it can’t it won’t start, and in most cases you have probably like me only run the domain preparation step on the domain you want to use with Lync.

There’s two ways to resolve this depending on your requirements,

  1. Run the domain preparation step on all domains in your active directory forest.
  2. (My Preferred) Limit the user replication to the domain you want to use with Lync with the following powershell:
    Set-CsUserReplicatorConfiguration -Identity global -ADDomainNamingContextList @{Add="dc=fabrikam,dc=com"}

The PowerShell included above will limit the replication to the “fabrikam.com” domain only, misleading as the command may be (‘Add=’) as default the value is null (you can check with “Get-CSUserReplicatorConfiguration”) which essentially means all domains.

I didn’t find this issue to be that well documented or resolution 1, so hopefully this will help anyone else out there who has the same problem (and maybe remind myself if I ever want to include additional domains and can’t figure out why I can’t enable the users for Lync).

Big thanks to “JMTTech” on the technet forums for this one http://social.technet.microsoft.com/Forums/nb-NO/lyncserverpreview/thread/07ec9d8c-b83e-4795-91b6-0d3344cd49e5