Office 365中批量添加用户 企业管理员在O365订阅中创建用户时，不可能像试用时那样一个一个地添加。在初始化企业订阅的时候往往需要批量添加用户，O365为我们提供了批量添加用户要用到的CSV文件模版及空白文件，用文本编辑器编辑该文件，按照文件的格式要求将用户记录逐条逐项对应填上就可以轻松完成用户的批量添加。如图：
在此图中可以下载CSV文件的示例和空白文档，用最简单的文本编辑器打开该文档的样子如下图：
最上边一行实际上是在O365中创建用户记录时会包含的字段，不能对这一行进行任何删改，否则无法通过系统验证。如果不能或不愿将每一个用户的所有信息都填全的话，"用户名"和"显示名称"这两个字段是必须的，其他字段可以用空格表示为空，字段与字段之间需要用半角逗号分隔。我做了一个示例，如下图：
编辑好了文件后，将其保存在本地硬盘的文件夹中，然后点击下图中"浏览"按钮找到刚刚保存的文件，并点击"下一步"按钮，如下图所示：
此时系统会对你提供的文件进行验证并给出验证结果，只有验证没有错误存在时才能够点击"下一步"按钮，否则需要处理报错并更正CSV文件中的错误后再次验证没有错误了才能继续，如下图：
接下来就是设置登录状态和用户位置，如下图：
点击"下一步"配置许可证，如下图：
再点击"下一步"设置将结果发送到哪些电子邮件，我这里只将结果发送给了自己，如下图：
最后点击"创建"按钮完成批量用户的创建，如下图：
点击"关闭"以结束本次用户创建工作。
最后，提醒大家注意以下几点：
- 刚刚上面提到过，"用户名"和"显示名"是必须的，为什么？请大家自己动手创建单个用户看一下，只有这两个字段是带红色*号的，为必填字段。
- 每一个CSV文件最多支持250个用户数据，超过次数需额外的CSV文件。每个文件至少要包含两行，标题行也就是用户属性的字段行，和一行用户数据行。
- 不能更改列标签的顺序，可以使用任何语言，支持保存为Unicode或UTF-8格式。
| 用户 名 （必需） | 用户名的最大总长度为 79 个字符（包括 @ 符号），格式为 name@domain.<扩展名>。用户的别名不能超过 30 个字符，域名不能超过 48 个字符。 |
| 名字 | 64 |
| 姓氏 | 64 |
| 显示 名称 （必需） | 256 |
| 职务 | 64 |
| 部门 | 64 |
| 办公室号码 | 128 |
| 办公室电话 | 64 |
| 移动电话 | 64 |
| 传真 | 64 |
| 地址 | |
| 城市 | 128 |
| 省/自治区/直辖市 | 128 |
| 邮政编码 | 40 |
| 国家/地区 | 128 |
更多精彩内容，敬请期待！
本文出自 "中国道" 博客，请务必保留此出处http://loveunicom.blog.51cto.com/121558/1255682
【DevOps】谁说大象不能跳舞? 很多企业，尤其是大企业在产品开发和运维上存在着一些普遍问题，比如开发周期长、人员合作程度不高、开发和运维脱节等等。可看看一些巨型企业，比如Google，Amazon，Facebook,Salesforce等等，人家的规模不比你大，架构不必你复杂？为什么他们能做到大而灵？
成功的因素固然有很多，而一个共同的因素是，他们都引入了DevOps的概念。
DevOps是基于Agile和Lean发展而来的一种理念，目的是更好的优化开发和运维的流程，从而更快、更高效的实现产品更新。DevOps是由Development + Operation缩写而来，但绝不是二者的简单相加。引入DevOps需要在企业文化和技术上都要落实一些措施。
在我们进一步介绍该理念之前，本文来探讨一些我见过的IT环境中的问题，尤其是在大企业中有普遍性的问题。
上图想说的是由于组织结构、文化以及技术局限性的多种原因，各个组负责自己的一亩三分地，别组的事情不管我事，我也根本不知道别人在干什么。那产生的后果呢，咱们从项目的各个环节一一道来。
设计阶段
需求分析和后面的环节脱钩。往往大费时间精力制定的需求，在后续阶段中不能很好的执行。可能的原因有：一需求本身的质量不高，没有很好的衡量手段和标准二需求没有体现整个LifeCycle，往往忽视运维中可能出现的问题三只注重Functional Requirements , 而忽略Non-Functional Requirement
另外需求更改是难免的，可合同已经签了。按照Change Control的规定，需要重新评估时间，人力及风险，这一趟下来时间上的损失不说，非常耗精力。
开发阶段
实施人员可能对设计本身的了解不透彻，更别说对需求的把握了。做出来的东西有时走了样，忘了本来的目的是什么。
测试阶段
Unit Testing，integration Testing, Performance Testing, Stress Testing, UserAcceptance Testing. 整个测试阶段耗时耗力，测试人员有时闲的要死，有时忙的要死。各个测试之间的协调也是问题。
运维阶段
大型复杂项目中往往一个Change需要涉及多个团队，本来30分钟的活儿，你要想每个组都批准Change可能要数天甚至数周。运维中出了问题呢，各个组之间扯皮推脱自是家常便饭。怕的是有的时候根本不知道哪出了问题，也可能整个系统靠个别技术牛人来撑着，其他人没有也不知道如何下手。
解决方案
发牢骚谁都会，那么有解决办法么？当然有，不过这可不是什么灵丹妙药，一吃就灵。需要从上至下，在文化上和技术上都要有下大力气才行。请关注下文将展开DevOps的一些实施细节。
本文出自 "坐看云起" 博客，请务必保留此出处http://frankfan.blog.51cto.com/6402282/1255642
没有评论:
发表评论