Recently my Microsoft Teams Desktop app started showing the error code caad0009 and I was unable to use the Teams app from thereon. This a rare sign-in error which indicates the service could not validate your credentials or recognize your device. Although it occurs quite rarely, this error primarily affects work and school accounts and it only occurs on the Windows Desktop app, i.e. you can still use the Teams browser version, Teams mobile app, or even the Teams Desktop app on a totally different Windows device. I searched quite some time to finally resolve this issue with a simple Powershell command. All other solutions didn't work for me.
The exact error message states:
Error code - caad0009 There's a more permanent way to sign in to Microsoft Teams. If you're having trouble completing the process, talk to your IT admin
Other solutions suggested things like
clearing the Windows Credentials cache
clearing the Teams Desktop app cache
re-installing Teams Desktop app
running Teams Desktop app in compatibility mode (e.g. Windows 7)
Someone even suggested that "it was a corrupt MicroSD card I had inserted couple of days a go, which prevented MS Teams and OneDrive from starting or signing in." Hilarious, really!
It came all down to WAM (web Account Manager) and ADAL (Azure Active Directory Authentication Library). By running this little Powershell command in an elevated Windows Powershell shell the Teams Desktop app started working again like a charm:
In my case the command took almost an hour to complete and it simply stood there with a blinking cursor with nothing seemingly happening. I just kept it that way and all of a sudden it completed successfully. And after that Teams Desktop started working immediately without having to reboot my PC or anything.
After upgrading the MFA component on our ADFS server it stopped working. Further investigation showed the following event ID error:
Encountered error during federation passive request.
Additional Data
Protocol Name: Saml
Relying Party: https://adfs.domain.com/saml/info
Exception details: Microsoft.IdentityServer.Web.NoValidStrongAuthenticationMethodException: No strong authentication method found for the request from https://adfs.domain.com/saml/info. at Microsoft.IdentityServer.Web.Authentication.AuthenticationPolicyEvaluator.EvaluatePolicy(Boolean& isLastStage, AuthenticationStage& currentStage, Boolean& strongAuthRequried) at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetAuthMethodsFromAuthPolicyRules(PassiveProtocolHandler protocolHandler, ProtocolContext protocolContext) at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetAuthenticationMethods(PassiveProtocolHandler protocolHandler, ProtocolContext protocolContext) at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)
Event ID 364, Source: AD FS, Log Name: AD FS\Admin
The upgrade inadvertently disabled the Multi-factor Authentication Method in ADFS:
In order to make it work again I had to enable the aforementioned MFA component in ADFS Management | Authentication Methods | Multi-factor Authentication Methos even though it may not be actively used:
If the emails remain on the Exchange server and cannot be forwarded to the smarthost for sending, it may be because the certificate bound to the corresponding connector no longer exists or has been expired. Of course, it is also possible that the expected subject alternate name (SAN) is missing or incorrect. In that case you may receive an error stating:
454 4.7.5 The certificate specified in TlsCertificateName of the SendConnector could not be found
You can verify whether you have such an issue by checking the mail queue:
Get-Queue
In case you have a lot of mails stuck in one of your mail queues you can further investigate the affected queue by running:
Get-Queue <queue name>
e.g. Get-Queue "SERV-MAIL\3" | fl
Having a look at the LastError property reveals the aforementioned error.
In my case the outbound Office 365 Send Connector was involved. In order to fix this I had to issue the following commands:
Today I came across an issue where printer auto creation failed for a couple of HP printers on one client computer only. The XenDesktop worker showed an Event ID 1106 stating Printer auto-creation failure. Reason: AddPrinter() failed with status 0x7A.
Searching for this particular error didn't reveal anything helpful. So I had to start digging into it by myself.
Converting hex 7A into decimal 122 and using net helpmsg122 does provide some additional information:
The data area passed to a system call is too small.
Searching for this error message revelead that there is an issue with the printer or the driver associated with it on the client. It looks like the printer drivers were not installed properly in the users PC. Re-installing the driver on the workstation solved the issue.
Just recently I happened to face a pretty annoying issue, that took me a couple of hours to solve. And by the end it was quite simple and obvious actually.
Long story short – newly implemented AD FS 4.0 farm, properly configured and already working. No funny claims rules, no additional authentication factors enforced, still login was working only for a couple of accounts with no obvious similarities or discrepancies. All users were created equal.
Testing was done by navigating to https://sts.domain.com/adfs/ls/idpinitiatedSignon.aspx and logging in with valid user credentials. For some users it worked and for others… well it did not. They were just thrown back to the login mask, no error message or anything.
Please note that the aforementioned endpoint is by default disabled in Windows Server 2016 ADFS 4.0. You have to enable it first by running:
Troubleshooting was quite a chore as no events were triggered and or logged in any of the available Event Logs or log/tracing files. When using bogus login credentials on purpose, e.g. wrong username or password, I received corresponding error messages of invalid username or password.
I use a managed service account (gMSA) for the ADFS service, as this is best practice and recommend by Microsoft.
As stated by Vasil Michev in his blog post (and answer to my problem):
Turns out, the service account was missing the required permissions. Simply giving the account Read access to the user account in question resolved the issue – the user was now able to properly use AD FS. As it turns out, the root cause was that the for whatever reason, the access entry for “Authenticated Users” was removed from the “Pre-Windows 2000 Compatible Access” group in the affected environments.
and
In addition, a very similar issue might occur if the application in question is not able to read the tokenGroupsGlobalAndUniversal attribute. To solve this, make sure that the service account is a member of the “Windows Authorization Access Group”.
Furthermore as stated by Aaron.H in the corresponding Microsoft Forums thread:
I discovered that the Pre-Windows 2000 Compatible Access group in my production domain did not have Authenticated Users as a member like the new lab domain did. Once I added Authenticated Users to the Pre-Windows 2000 group, I was able to authenticate using regular domain accounts to ADFS.
Another reply states:
I just added the service account (which was created manually rather than a managed service account) for adfs to the Pre-Windows 2000 group and that resolved my issue, so you don't have to add the Authenticated Users group if you don't want to.
And a final statement on this issue:
Don't know if you guys solved it by now but i wanted to let you know the Pre-windows 2000 Group membership didn't work for me. However when i added the ADFS group managed service account to the ' Windows Authorization Access Group' it worked instantly. According to the description of this group ('Members of this group have access to the computed tokenGroupsGlobalAndUniversal attribute on User objects') this is expected behaviour.
There are a lot of reasons why correct permissions are not being assigned throughout the domain. The adminCount attribute, disabling inheritance, et al. So thanks to all guys involved in this issue and for clarifying things!
While running the Active Directory Federation Services Configuration Wizard for the first time on a newly installed Windows Server 2016, I ran into the following error after deciding to create the first federation server in a federation server farm, and creating a Group Managed Service Account (gMSA) as Service Account for my ADFS implementation:
The specified service account 'CN=svc-ADFS-gMSA' did not exist. Attempt to create the group Managed Service Account failed. Error: There is no such object on the server.
During troubleshooting it turned out that the underlying issue actually lay far deeper than expected...
At first all prerequisites checks passed successfully:
Prior to running the Configuration Wizard I succesfully created the Key Distribution Services KDS Root Key for the gMSA by executing:
What did I miss? Well, silly me, I simply did not provision the gMSA prior to running the Configuration Wizard, though the Configuration Wizard states, that it will create a gMSA if it does not already exist:
So, how do I successfully create a corresponding gMSA in order to make it work with AD FS?
You can provision a gMSA using the New-ADServiceAccount cmdlet, where domain.com ist the your own TLD:
Verify whether the gMSA has been successfully provisioned in the corresponding OU provided with the -Path parameter:
Verify whether all required Service Principal Names (SPN) have been registered and associated with the newly provisioned gMSA by executing the following command:
setspn /l svc-ADFS-gMSA
After running the Configuration Wizard again it still fails with an error stating:
The system cannot find the file specified
Doing a Little Research resulted in "the GMSA was moved from the Managed Service Accounts container in Active Directory" and "make sure you have a Managed service account group object in ADUC. (not an OU)". Checking my Active Directory I realized that the required container Managed Service Accounts is actually missing! And I was unable to identify the reason why it was missing in the first place. Looking into my Deleted Objects container came up … empty.
So, how do I successfully re-create a corresponding Managed Service Accounts container in order to make it work with AD FS?
Further researching revealed I had to re-create a corresponding container with ADSIEdit named "Managed Service Accounts" and ensure ist security properties are correctly set to "Enable Inheritance".
Then I deleted my previously provisioned gMSA:
After that I ran the AD FS Configuration Wizard again and it was completed successfully:
Checking the AD FS Service as well as the corresponding Event Log showed that all went well:
Just recently I came across an expired Server Certificate on my Citrix License Server v12.x. As everybody might know, the Citrix License Server is based on an Apache Tomcat webserver running on your Windows Server. During installation a self-signed server certificate is being issued and bound to the Apache's web server port 8083. So how are you supposed to renew the server certificate in case it has expired and you need secure access to the corresponding Citrix License Server features?
To help you set up NetScaler for ShareFile with on-premises storage zone controllers, an easy-to-use wizard is included in the GUI. The wizard prompts you for basic information about your StorageZones Controller environment and then generates a configuration that:
Load balances traffic across StorageZones Controllers
Provides user authentication for StorageZone Connectors
Validates URI signatures for ShareFile uploads and downloads
Terminates SSL connections at the NetScaler appliance
After running the built-in Setup Citrix ADC for ShareFile wizard, users starting complaining that they cannot access their network shares anymore. Those network shares have been provided via the integrated ShareFile Connector's funcionality and has been up and running very smoothly prior to adding Netscaler to the equation.
As soon as users tried to access a network share via a StorageZone Connector they received an error indicating "Failed to load folder -The folder you are looking for could not be found":
As per Citrix, you may see following error while accessing Network Shares on ShareFile Web App:
The folder you are looking for could not be found. This can occur if the link you used is incorrect, or if it points to a folder that has been deleted or to which you do not have access.
Mind that this happened with the ShareFile Web App only while accessing network shares, i.e. using within a browser, whereas accessing the exact same network share via Citrix Files for iOS worked like a charm. After having consulted our change management documentation, it quickly became clear that only one culprit could remain, as there has been no change in user passwords, permissions, group memberships, UNC paths regarding the underlying network shares, et al. All users have required permissions. The root cause could only be traced back to the changes in the Netscaler configuration a couple of days earlier. So I started investigating the details of the Setup Citrix ADC for ShareFile wizard, its configuration changes and effects on my setup by reading ShareFile On-prem and NetScaler: A Comprehensive Configuration Guide & Deep Dive, amongst others:
In case you messed up with your ShareFile Configuration: you can try to remove it with Remove ShareFile Configuration
With having a better understanding of all things Netscaler & Sharefile, I did a little research and found a Citrix Discussion dealing with my issue and it turned out that the Setup Citrix ADC for ShareFile wizard (to the contrary) does not handle all the configuration required to access network shares via a StorageZone connector. Further configuration as to be done manually to make it work (again), as can be read here:
To support restricted zones or web access to StorageZone Connectors, you must perform additional NetScaler configuration after you complete the NetScaler for ShareFile wizard.
The additional configuration provides the Netscaler components shown in the following diagram:
The description of the additional configuration of Netscaler in Citrix Docs is - to say the least - not very accurate. Without appropriate formatting of the corresponding text passages and additional depictions illustrating every single configuration step, manual adjustments are difficult to comprehend for non-Netscaler-aficionados. Therefore I'd like to expand on Citrix Docs and provide a more elaborate description of the configuration steps required. So, what do we need to add to the existing Netscaler configuration:
a third NetScaler load-balancing virtual server
a third CS policy to allow anonymous access from clients for the HTTP OPTIONS verb
update the existing CS policy used for traffic to StorageZone Connectors (by default: _SF_CIF_SP_CSPOL)
update the existing CS policy used for traffic to StorageZones for ShareFile Data (by default: _SF_SZ_CSPOL)
create a heartbeat monitor for the StorageZones Controller service and bind it to the CS virtual server for ShareFile
verify the ShareFile Load Balancing configuration
First, add a new Load Balancing vServer as follows:
In the end your CS policies should look like this (in terms of Expressions):
final CS policies and corresponding Expressions
Now adjust the existing CS vServer for Sharefile (in my case vsrv_SF_CS_ShareFile) regarding its Policy Bindings in that you add the newly created CS Policy (in my case _SF_ZONE_OPTIONS_CSPOL) as the third CS policy with a Priority of 90 and set the Target Load Balancing Virtual Server to the newly created LB vServer (in my case vsrv_SF_ZONE_OPTION):
The StorageZone Hearbeat Monitor can be added using CLI by running the following commands:
add lb monitor SZC_Heartbeat HTTP-ECV -send "GET /heartbeat.aspx" -recv "***ONLINE***” -secure YES
bind service <Name of your LB service i.e. internal SF server> -monitorName SZC_Heartbeat
The newly added StorageZone Heartbeat Monitor should look as follows:
StorageZone Heartbeat Monitor Configuration
The complete CLI command list would look like this, whereas the following values need replacement according to your environment:
CertDisplayName (server certificate name you want to bind to your vServer)
NameOfYourSFServer (i.e. the Sharefile Server you've added to your NetScaler configuration)
NameOfYourSFCSvServer (i.e. the Sharefile Content Switching vServer)
Finally, go to Traffic Management > Load Balancing > Virtual Servers to view the status of the load balancing virtual servers created for ShareFile. It may look similar to my configuration:
Virtual Servers configured for ShareFile Load Balancing
While testing your new configuration and accessing network shares via ShareFile connectors you should see an increasing hit number in the Hits column of your corresponding CS policies:
Increasing hit number in the Hits column
Update You have to consider network restrictions as well, as Security can mess with ShareFile traffic and network flow, especially when Firewall settings do not allow corresponding (read: whitelisted) traffic to ShareFile domains, endpoints, and IPs, i.e. the ShareFile Control Plane IP ranges. Have a look at CTX208318 and CTX234446.
In another case, if you attempt to access the ShareFile network share and it prompts for users credentials, the ShareFile Web App credentials may not work. Have a look at CTX233739 as well:
Solution Authentication settings of an IIS CIFS server on StorageZone Controller needs correction. Please follow the steps to resolve the issue:
1. Log onto the StorageZone Controller(s) and open IIS. 2. Expand Default web site 3. Click on the CIFS virtual directory, then on Authentication. 4. Ensure Anonymous is Enabled 5. ASP .NET Impersonation is Disabled 6. Basic Authentication is Enabled 7. Forms Authentication is Disabled 8. Windows Authentication is Disabled
Reference: The Authentication settings of an IIS CIFS server
Just recently I came across an interesting support case which involved an Exchange 2010 Offline Address Book (OAB) and Outlook 2010 clients trying to download it. The affected users received an error stating: Error 0x80190194 - The operation failed. Problem is, this is a very common error when downloading the OAB and there are many server side problems which can generate this error:
missing or misconfigured OAB distribution settings (server-side)
OAB generating mailbox issues (server-side)
DAG replication issues and arbitration mailbox (server-side)
missing or misconfigured proxy settings (client-side)
download issues in terms of BITS (client-side)
et al
Troubleshooting methodology
In order to identify the affected OAB that my users tried to download I first had to get hands on the corresponding OAB GUID by running:
Get-OfflineAddressBook | ft Name,GUID
With the OAB GUID identified I started testing with a browser by navigating to the corresponding URL https://<ServerFQDN>/OAB/<GUID>/oab.xml, checking each server separately. I thereby received an Error 404 - Not Found on one of my servers, which in turn resulted in the aforementioned Outlook error 0x80190194 for my users. This error (which is basically a 404) appeared sporadically depending on the Exchange 2010 Server they were redirected to through our Load Balancer:
Further research on the server showing the Error 404 in particular showed that OAB with GUID 72189f79-62fa-4bcf-82ea-56dc45cfdeb0 is missing in IIS under the OAB node, thus assuming that this particular OAB has not been replicated between my Exchange 2010 Servers:
Missing OABs in the file system ... check the Microsoft Exchange File Distribution Services (MSExchangeFDS) on the affected server
The following location on the Client Access Server can be checked to see if the OAB files have been replicated:
I copied the missing web.config file as well an restarted the MSExchangeFDS service, to no prevail. Then I executed Get-OfflineAddressBook "<OAB Name>" | Update-OfflineAddressBook to no prevail. Finally I execute iisreset to no prevail.
Well, checking the distribution methods for the affected OAB revealed that the 2nd Exchange 2010 Server was missing in the Distribution tab of the OAB's Properties. I should have done this in the first place 🙂
After adding the missing Exchange 2010 Server and restarting the Microsoft Exchange File Distribution service by executing Restart-Service MSExchangeFDS the replication started immediately. The missing OAB showed up in IIS as well as in the folder structure.
Alternatively you could run the following cmdlet to initiate the OAB replication:
But even after a successful OAB replication I still received an http error 500 - Internal Server Error when acessing the OAB via browser in order to verify that everything's fine:
So, back to the web.config file, that was presumably missing the first time around. What does a web.config file actually do when placed in the OAB file directory:
When you configure Http Redirection a web.config file is created in the OAB directory. This file has incorrect permissions. Assign Read and Read & Execute permission to Autheticated Users group then restart IIS using iisreset /noforce.
Now you can try to download the OAB using Outlook. It may be required to download it twice because sometimes the name of the OAB doesn't appear at first try.
Well, that didn't count for me so I checked the web.config and IIS settings to verify whether any settings have been adjusted in the past that I didn't know of. As that wasn't the case I deleted it, but the issue still persisted.
Verify OfflineAddressBook property on the affected user's mailbox and adjust the missing OAB association:
With a corresponding Event Log entry on the client computer, Event ID 27, Source: Outlook, the issue can be further analyzed by following Microsoft's KB843483 article:
In my case the error messages stated exactly what I tried to achieve:
Result Code 2, i.e. You forced a full .oab file download manually.
Furthermore I checked some other client-side settings and known issues that could cause an OAB download error, such as whether BITS has some kind of problem when trying to download the OAB. An error 0x80200049 is often caused from the BITS job list being full. To fix this, you must clear/reset the BITS job list. Microsoft outlook uses BITS to download the OAB and if the BITS queue goes full it simply stops:
bitsadmin /list /verbose
bitsadmin /reset
The client-side proxy settings, i.e. the client should have unobstructed access to Exchange via https:
netsh winhttp show proxy
netsh winhttp reset proxy
netsh winhttp set proxy <proxy>:<port>
In the end the last thing I had to ensure and configure was to enable GlobalWebDistribution for all my Exchange 2010 OABs in order to prevent server-specific connections when clients try to download the OAB:
In my particular case that did it: the issue was resolved and setting the VirtualDirectories property to $Null reverted my solution attempt that I suggested previously 🙂 And I can tell you why: because my environment consisted of Exchange 2010 and Exchange 2016 Servers due to being in the middle of a migration.
Update:
With Exchange 2013 onward the CAS role proxies the OAB download request to an appropriate Mailbox role server. The CAS role maintains a log of each request it handles in the log files, present in folder %ExchangeInstallPath%\Logging\HttpProxy\OAB\. These log files are an excellent tool to identify which mailbox server the CAS chose to serve the request. Download issues can be analyzed with log files found in %ExchangeInstall%\Logging\OABDownload. The OAB generation logs can be found in the \Logging\OABGeneratorLog folder.
Maybe one of the steps outlined above will help you, too, to get rid of issues with downloading OABs for good.
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
