SMLets new Configuration Questions #524
-
|
I have a SCSM 2022 Server we installed the SMLets Management Pack. The mailbox user is cloud only account with a mailbox license, the SMLets Exchange Connector settingis setup for the O365. Workflow email address is the one for the cloud only user but on the drop down we have tested with the same cloud only account but still we received the below errors. Should the Workflow Account in SCSM be change to a Cloud only account as well? I am at a dead end here some of the other discussion point is not helping me System.Management.Automation.MethodInvocationException: Exception calling "Bind" with "2" argument(s): "The Url property on the ExchangeService object must be set." ---> Microsoft.Exchange.WebServices.Data.ServiceLocalException: The Url property on the ExchangeService object must be set. Could not retrieve OAuth token from 365: System.Net.WebException: The remote server returned an error: (400) Bad Request. The address/SCSM Run As Account used to sign into 365 is not a valid email address and is currently entered as @. This will prevent a successful connection. To fix this, go to the Run As account in SCSM and for the username enter it as an email address like user@domain.tld System.Management.Automation.MethodInvocationException: Exception calling "LoadFile" with "1" argument(s): "An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information." ---> System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 5 replies
-
|
Beta Was this translation helpful? Give feedback.
-
|
Sound good on all fronts. On point 4, this depends. If you're using the workflow account it is is probably underneath the Service Manager Core Library. If you created a new run as (which is what you most likely did given this discussion), you should expect to find it under the Service Manager Linking Framework Configuration. For the sake of argument, could you try your true domain name instead of the onmicrosoft one? This shouldn't matter but I just want to verify. Follow up question, you are not using Impersonation correct? Just want to verify as this is no longer possible since about this time last year. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @AdhocAdam We found the issue and it was the Workflow for the SMLets Exchnage Connector that dont run. We ended up disabling it and reverted to Task scheduler job and hit a wall with the SecretVault. Then we figured out to run PowerShell as the Workflow account to set the SecretVault and Secret but had to turn off the interactive mode for the Secret Configuration otherwise the task scheduler job hangs as it opens a Powershell windows that request the password to open the secrets. Lots of hair pulling but we managed to get it working in the end with the Workflow to check the Cloud mailbox with Task Scheduler and the script. Another thing that is not in the wiki is that is you decide to not use the SCSM workflow youmust edit the script and add the username, domain and the get-secret -asplaintext command Cheers |
Beta Was this translation helpful? Give feedback.
-
Would you mind expanding on this further? I'll gladly update the wiki. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @AdhocAdam Let me see if I can articulate this correctly. For the Set-Secret we logged on to the server with the SCSM Workflow account and ran PowerShell. In PowerShell we ran the following commands so that we can set our Secret as well as remove the interactive prompt top enter a password to access the secret.
In the Task Scheduler we created the task as per your article and select the SCSM Workflow account to be used to run it whether logged in or not and the Azure App Registration. We imported the MP for the SMLets Exchnage Settings in the GUI. We removed the tick from the workflow so that we can make use of the PowerShell script smletsexchangeconnector.ps1 Within the connector script we added the username to the $username variable, the same for the $domain variable, when we got to the $password we set it to $password = Get-Secret -Name "SMExcoSecret" -AsPlainText this reads the password from the vault and makes it available to the rest of the script. This intern will allow the task scheduler job to run unattended. Hope it makes sense from what I typed here to me a good 4 hours to figure this out as all the error in the Event viewer was not helpful as it gave me the right username format and ClientID. Also all MFA needs to be excluded for the Cloud Native Mailbox Cheers |
Beta Was this translation helpful? Give feedback.
Hi @AdhocAdam
Let me see if I can articulate this correctly.
For the Set-Secret we logged on to the server with the SCSM Workflow account and ran PowerShell.
In PowerShell we ran the following commands so that we can set our Secret as well as remove the interactive prompt top enter a password to access the secret.