从 C# Web API 方法中创建 Office365 邮箱 [英] Create an Office365 mailbox from within C# Web API method

查看:49
本文介绍了从 C# Web API 方法中创建 Office365 邮箱的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

上下文

我有一个由 ASP.NET MVC 应用程序调用的 ASP.NET Web API 应用程序.

在 Web API 中,我有一个方法需要在其他东西中创建 Office365 邮箱(创建文件夹、创建联系人、创建签名等……)

该邮箱的创建实际上隐藏了需要以特定顺序发生的几个步骤:

  1. 在本地 Active Directory 中创建用户(返回 true 或假).
  2. 强制 AD Connect 在本地 AD 和Azure AD 因为有一个默认的 30 分钟延迟,我们迫不及待因为,因此我们需要强制同步(返回 void).
  3. 验证Office365账号是否存在(返回true或假).
  4. 验证我们是否仍有可用的 Office365 许可证可分配给那个用户.

<块引用>

(注意:如果没有足够的许可证,将发送一封电子邮件购买更多许可证...)

  1. 将 Office365 许可证分配给该用户.

<块引用>

(注意:我相信将许可证分配给用户的操作实际上会创建邮箱...如果我错了请纠正我)

  1. 在该用户的邮箱下创建几个文件夹(返回无效).
  2. 新建两个联系人(返回无效).
  3. 创建签名(返回无效).

问题

我对一些事情有点困惑...首先,其中一些任务(不是全部)可以通过使用 Microsoft Graph 来完成,而其他任务则不能,因为 Graph(目前)还不支持.

其次,我可以通过使用一些 PowerShell cmdlet 来完成其中一些任务(例如:强制 AD Connect 同步).事实上,我确信上述所有步骤都可以使用多个 cmdlet(或简单地组合在一个大的 PowerShell 脚本中)来实现.

第三,我正在抓住稻草,以了解解决此问题的最佳方法.

例如,考虑到我在 HttpRequest 的上下文中,我的 Web API 方法是否应该混合使用一些 PowerShell cmdlet 和一些 Microsoft Graph?

我应该将两者混合吗?还是不行?

我是否应该找到所有 cmdlet,将它们按顺序放置在一个大 PS1 文件中,然后从我的 Web API 方法中简单地执行那个大 PS1 文件?

我是否应该找到隐藏在每个 cmdlet 中的所有 Web API 并改用这些 Web API 调用?

我似乎在每个方面都发现了一些优点和缺点,并且无法确定最好的.

我担心如果我尝试直接从我的 C# 代码中运行 cmdlet,如果其中一个 cmdlet 失败或引发异常,那么如何处理?同样,如果我将所有内容都放在一个大文件中...

不幸的是,我的问题似乎多于答案,也许有人可以帮助我阐明这一点:-)

真诚的

PS:虽然也许更好的解决方案是将 Azure Functions 与某种队列一起使用,但不幸的是,我对 Azure Functions 不够熟悉,也没有时间实现更好的方法.如果可能的话,我想坚持在 Web API 方法中实现这一点.

解决方案

据我了解,Microsoft Graph 只允许我们操作 Office 365 等微软云资源.

它无法使用它或其他 REST 服务来强制 Azure AD 连接以同步从本地到云的更改(Start-ADSyncSyncCycle -PolicyType Delta).与其将业务逻辑混合到不同的地方(C# 和 Powershell 代码),我想将其保持在同一个地方(本场景中的 PowerShell 脚本)以便于维护.我们需要在 PowerShell 脚本中编写异常/错误处理.

希望对你有帮助.

Context

I have an ASP.NET Web API application invoked by an ASP.NET MVC application.

Inside the Web API, I have a method that will need to create an Office365 mailbox amongst other stuff (create folders, create a contact, create a signature etc.…)

The creation of that mailbox actually hides few steps that need to occur in a particular order:

  1. Create a User in the local Active Directory (return true or false).
  2. Force AD Connect to synchronize between the local AD and the Azure AD because there is a default 30 min delay which we can’t wait for, hence why we need to force the synchronization (return void).
  3. Verify if the Office365 account exist or not (return true or false).
  4. Verify if we still have available Office365 licenses to assign to that user.

(NOTE: if not enough licenses, an email will be sent to purchase more licenses...)

  1. Assign Office365 license to that user.

(NOTE: I believe the action of assigning a license to a user actually creates the mailbox...correct me if I’m wrong)

  1. Create a few folders under that user’s mailbox (return void).
  2. Create two new Contact (return void).
  3. Create a signature (return void).

Question

I’m a bit confused with a few things...firstly, some of these tasks (not all) can be achieved by using Microsoft Graph while other tasks simply can’t because Graph doesn’t support it (yet).

Secondly, I can achieve some of these tasks (for example: force AD Connect to sync) by using some PowerShell cmdlets. In fact, I’m sure the entire steps above can be achieved using multiple cmdlets (or simply combined within one big PowerShell script).

Thirdly, I’m grasping at straws to understand what is the best way to tackle this.

For example, considering I’m in the context of an HttpRequest, should my Web API method use a mixture of some PowerShell cmdlets and some Microsoft Graph?

Should I be mixing both? Or not?

Should I instead, find all the cmdlets, place them in order inside one big PS1 file and simply execute that one big PS1 file from within my Web API method?

Should I instead find all the Web API hidden inside each cmdlets and use those Web API calls instead?

I seem to find a little bit of Pros and Cons in each and can’t settle on what’s best.

I have concerns that if I try to run cmdlets directly from within my C# code that if one of the cmdlets fails or throws an exception, then how to handle that? Likewise if I put everything in one big file...

Unfortunately, I seem to have more questions than answers and perhaps someone can help me shed some light on this :-)

Sincerely

PS: Although maybe a better solution would be to use Azure Functions with some kind of Queue but unfortunately, I’m not familiar enough with Azure Functions nor do I have the time to implement a nicer way. If possible, I’d like to stick with making this happen within the Web API method.

解决方案

Based on my understanding, the Microsoft Graph only allow us to manipulate the Microsoft cloud resource like Office 365, etc.

It is not able to using it or other REST service to force Azure AD connect to synchronize the changing from local to cloud(Start-ADSyncSyncCycle -PolicyType Delta). Instead of mixing the business logic to different places(C# and Powershell code), I'd like to keep it in the same place(PowerShell script in this scenario) to easy to maintain. And we need to write the the exception/error handling in the PowerShell script.

Hope it is helpful.

这篇关于从 C# Web API 方法中创建 Office365 邮箱的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆