通过 COM 从 Orchestrator 中获得更深入的信息

我发现很多用户请求利用 Orchestrator 来创建集成,以获得一些有关某一安装过程的内部工作机制的信息,而这些信息都是无法通过 Web 服务所获得的。Web 服务可让您检索有关以下内容的信息: 文件夹 Runbook Runbook 参数 活动 作业 Runbook 实例 Runbook 实例参数 活动实例 活动实例数据 Runbook 服务器 Runbook 关系图 统计信息 事件 除了开始作业和停止作业以外,其他所有通过 Web 服务所获得的内容都是只读的。但是,用户还希望能够进行编程操作(和修改操作),并执行类似于以下的操作: 查看并修改变量和计数器 查看安装了哪些集成包 查看日志历史记录 导出或导入 Runbook 签入或签出(或取消签出)Runbook 查看哪位用户拥有连接到 Management Server 的 Runbook Designer 所有这些功能,以及更多功能均已通过 Orchestrator COM 界面可用。我将撰写一篇新的文章来解释如何连接到 COM 界面,并使用该界面来进行多个有助于您进一步自动化与 Orchestrator 交互的操作。由于使用 C# 代码进行编写和编译更为简单(对我而言这比使用 C++ 简单多了),因此我将在这些示例中使用 PowerShell。 首先,我将打开一个 PowerShell (x86)…

1

创建无需排队的单实例 Runbook

Orchestrator 的一个妙处是它可以自动处理 Runbook 的多实例线程,或者根据您的需要将它们排队。例如,您可以将处理新用户的 Runbook 添加到 Active Directory,对于大公司而言,可能存在多个并发请求,因此可能需要运行 Runbook 的多个实例。或者,您可能有一个更改系统的事务类型的流程,并希望确保在多个用户请求更改时将这些请求排队并按顺序运行,以避免相互之间发生潜在冲突。通过 Runbook 的“属性”对话框中的“作业并发”选项卡可以轻松控制此 Runbook 行为: 默认情况下,该值设置为 1,这意味着一个 Runbook 将运行一个实例,并将所有其他请求排队。如果希望增加此数字,以允许多个并发实例,只需将该数字调大一些即可。相当容易,不是吗? 但是,如果您有一些作业需要作为单一实例运行,但希望在当前作业完成之前忽略所有其他请求,应该怎么办?此情况的一个示例是云服务的自动横向扩展。让我们假定您在使用 Operations Manager 监视一个服务,一个性能警报触发一个 Runbook,开始横向扩展该服务。该横向扩展进程可能需要一些时间,并且在该进程完成之后可能还需要一段时间,以使性能平均数下降到一个可接受的范围(我们称其为“冷却”期间)。无论出于何种原因,都可能会再次触发警报,告诉 Orchestrator 纵向扩展该服务。如果已经有一个 Runbook 正在纵向扩展该服务,您不希望接受任何其他请求,当然也不希望只是将它们排队。您知道您只是想忽略或丢弃任何请求,直到此 Runbook 完成之后为止。那么如何处理此情况? 注意:与任何示例一样,我向您展示的是一个相对简单的视图,在现实世界中,您拥有的可能是一些更为详细的逻辑。不过,我认为通过这个基本示例可以学到这种理念,并在自己的环境中根据情况举一反三。 首先,创建一个新的 Runbook。现在,如果希望避免将 Runbook 作业的请求排队,我们首先需要做的是增加同步作业的数量。在上面所示的对话框中,我们将该数字增加到了 10(这样,如果后续请求快速连发,我们可以处理它们而无需排队)。 接下来,将“初始化数据”活动和“查询数据库”活动拖放到 Runbook 并将它们链接起来。 我们在这里完成的工作基本上是,在 Orchestrator 数据库中查询包含此 Runbook 中“初始化数据”活动的活动 ID 的任何活动作业 (TimeEnded = NULL)。但是我们需要采取迂回的办法完成此工作。在运行时我们无法访问 Runbook 的 ID,因此我们需要使用连接两个表的查询从活动 ID 中推测该 ID,如下图所示: 您可能会注意到,查询中执行了一些奇怪的字符串替换。此问题是由于每个活动的活动…

0

使用Azure HDInsight大数据技术来进行Azure WebSites网站及其他日志文件分析(Log Analysis)

原文地址:http://blogs.technet.com/b/nevin_dongs_blog/archive/2015/03/07/azure-hdinsight-azure-websites-log-analysis.aspx 在使用大数据(Big Data)的实际应用场景中,日志文件是一个很重要的数据来源。相比其他数据源,日志信息总在源源不断的产生中,不论是系统或代码中设置好的触发/生成机制,还是系统(例如 Web Server、Database Server等)配置自动生成的日志,甚至包括了系统或应用执行发生异常或错误的情况,例如,SQL Server Azure VM上AlwaysOn高可用(HA)方案的运行状态相关的日志。 而日志文件里所潜藏的价值也正被大数据技术所挖掘,透过对于日志文件一些基础数据的统计、挖掘及分析,可以进一步获得很多非常有用的信息,例如,对网站日志的分析,可以获得页面的点击的情况、外部访问的情况、客户端/服务端错误的情况等,从而进一步分析网页运行的健康度、使用率分布、访问者行为等。 在 Azure 中提供了 HDInsight 云服务来帮助大家进行大数据开发工作,可以把相关数据文件存储在 Azure Storage 中,然后利用 HDinsight 节点来对这些数据进行分析。 在 Azure HDInsight 的查询控制台(Query Console)中,最近提供了一些辅助性的解决方案,其中就包括了如何快速、简捷地建立日志文件分析的应用。如下图可在 HDInsight 服务页面的底部进入查询控制台: 在查询控制台可以看到一些解决方案的样例,就包括了对 Azure WebSites 日志文件分析的解决方案,见下图: 在搭建和运行Azure WebSites网站时,需要对日志选项进行配置,确保可以根据需要保留网站的运行日志信息,如下图: 在查询控制台的日志分析解决方案中,提供了 step-by-step 的执行向导,并提供了详细的解释信息,便于大家了解其中相关的技术细节。如下图: 其中,关键步骤包括了基于日志文件的数据结构,创建 Hive 的表及分区,如下图,解决方案中列出了具体创建过程的语句: 解决方案提供了一些常见的分析,并提供了样例程序,可以基于这些代码进行修改,满足自己的需要。 执行结果可以通过 Excel 来展现,并可以利用大家熟悉的工具,例如 PivotChart,来做进一步分析。 此外,还可以通过查询控制台,查看任务的输出及执行的Log。

0

中国版SharePoint 应用商店已正式上线

      中国版SharePoint应用商店已于近日正式上线。SharePoint商店是用户可通过SharePoint 网站直接访问、购买第三方开发人员所发布的个人或企业应用程序的公共商城。SharePoint 的应用程序是用以执行某项特定任务或满足某项业务需要的独立应用程序,轻便灵活,简单易用。用户可以将免费或付费的应用添加至网站,自定义设置以便使用某些特定功能或显示信息。 具体购买添加操作请参见以下步骤: 要将应用程序添加到网站,您必须至少有该网站的完全控制权限。如果您是网站所有者,那么您已经拥有此权限。 1.    在要添加应用程序的网站上,转到“设置” >“添加应用程序”。 2.    在“您的应用程序”页面上,单击左侧导航中的“SharePoint 商店”。 3.    使用左侧的“类别”筛选选定内容,并通过浏览找到所需的应用程序。 或者,如果您已经知道所需的应用程序的名称或标签,则可以在搜索框中键入该信息并直接进行搜索。 4.    单击您要添加的应用程序。单击“详细信息”或“评论”以了解有关应用程序的更多信息。 5.    如果您要购买此应用程序,请使用价格下的下拉列表来指定您是要购买该应用程序以供自己使用还是供多位用户使用。如果需要,请指定要购买的用户许可证数量。 6.    要购买应用程序,请单击“购买”。(如果它是一个免费应用程序,则单击“添加”。) 7.    按照相应步骤使用您的 Microsoft 帐户登录以购买应用程序。 8.    当系统询问您是否要信任该应用程序时,请查看来自应用程序开发商的条款和条件以及隐私声明,然后单击“信任它”。 9.    应用程序现在将显示在“网站内容”页面上。您可以通过在“网站内容”页面上单击该应用程序进行访问,这将使您转到该应用程序。 扩展知识: Microsoft 帐户并不等同于工作或学校帐户,如果您还没有 Microsoft 帐户,则可以注册一个。 SharePoint 商店中的部分应用程序是免费的,其他应用程序可供购买。 即使管理员并未将您的网站配置为允许用户购买应用程序,您仍然可以请求购买应用程序。您的组织中负责管理应用程序目录网站的人员可以批准或拒绝购买应用程序的请求。 注:Office 和 SharePoint 应用商店是可选服务,由 Microsoft Corporation 或其分支机构从 Microsoft 分布在全球的任一设施运营。应用商店中提供的应用由各种应用发布者提供,受应用发布者的条款和条件以及隐私声明的约束。您使用其中的任何应用可能会导致您的数据被传输到应用发布者、其分支机构或服务提供商维护设施所在的国家/地区,或者在那里存储或处理。特定应用和支付方式的可用性取决于您所在的地区和服务。下载和使用此类应用之前,请仔细阅读应用发布者的条款和条件以及隐私声明。

0

Azure 中的多个 VM NIC 和网络虚拟设备

原文地址:http://azure.microsoft.com/blog/2014/10/30/multiple-vm-nics-and-network-virtual-appliances-in-azure/ 在2014年欧洲 TechEd 大会上,我们宣布了在 Azure VM 中为多个网络接口(NIC)提供支持,并与多家重要厂商合作,在 Azure 中引入了网络虚拟设备,其中最引人注目的是 Citrix Netscaler 和 Riverbed 设备。很多网络虚拟设备都要求使用多个 NIC 。现在您可以在 Azure VM 中创建多个 NIC。借助多个 NIC,您可以更好地管理网络流量。您也可以将前端 NIC 和后端 NIC 之间的流量隔离开来,或者将数据层通信与管理层通信分开。以下是含有 3 个 NIC 的 VM 示例: 如何创建含有多个 NIC 的 VM 以下说明将帮助您创建一个含有3个NIC的VM:默认NIC和两个额外的NIC。配置步骤中使用包含 3 个子网的虚拟网络:Frontend(10.1.0.0/24)、Midtier (10.1.1.0/24) 和 Backend(10.1.2.0/24),虚拟网络名称为 “ThreeTier-VNet”,如下所示:   以下配置cmdlet使用最新的Azure PowerShell版本。请按此处的说明下载和配置 Azure PowerShell。 1. 从 Azure VM 影像库中选择一个 VM 映像 :…

0

Microsoft Migration Accelerator简介

原文地址:http://azure.microsoft.com/blog/2014/09/04/introducing-microsoft-migration-accelerator/ 我怀着无比激动的心情宣布 Azure Migration Accelerator (MA) 限量预览版上线。MA由InMage 收购技术衍生而来,旨在将物理、VMware、Amazon Web Services 和Microsoft Hyper-V工作负载无缝迁移至Azure。它会自动执行迁移操作的各个方面,包括发现源工作负载、远程代理安装、网络适应性和端点配置。有了MA,能够降低迁移项目的成本和风险。 MA 通过提供以下优势改变了云迁移范式: 异构性:您可以通过 MA 迁移各种平台(如VMware、Microsoft Hyper-V、Amazon Web Services和/或环境中的物理服务器)上运行的工作负载。MA 可支持Windows Server 2008 R2 sp1、Windows Server 2012 和 Windows Server 2012 R2操作系统上运行的工作负载。 简单的自动化迁移:MA门户允许您从云中远程自动发现企业工作负载。只需单击几次,即可配置端到端迁移场景。MA允许您在云中测试工作负载,并且不会影响现有的本地生产工作负载,从而在执行直接转换之前验证工作负载功能性。 迁移多层应用程序:让MA引以为豪的是,它不仅可以迁移多层生产系统,还能在各层实现应用程序级一致性。这样可确保多层应用程序在Azure中的运行模式与在来源中的运行模式完全相同。甚至可以遵循应用程序启动顺序,并且无需任何手动配置。 持续复制,最低直接转换时间:MA for Azure提供了全系统复制,包括操作系统和应用程序数据。这种持续复制和内存更改跟踪功能可将直接转换时间缩短至短短几分钟,最大限度地降低了对生产工作负载的影响。 MA 的工作原理 MA 运用多个组件安排迁移项目,如下图所示: 移动性服务:这是源服务器(本地物理或虚拟服务器)上的轻型(基于来宾机)集中部署代理。负责实时捕获数据,并将所选的源服务器卷同步到目标服务器。 流程服务器 (PS):本地物理或虚拟服务器。促进简化移动性服务与Azure内部的目标虚拟机之间的通信。提供缓存、队列、压缩、加密和带宽管理。 主要目标(MT):复制本地服务器磁盘的目标。安装于Azure订阅的专用Azure VM中。磁盘与 MT 相连以维护重复的副本。 配置服务器 (CS):管理主要目标与 MA 门户之间的通信。安装于Azure订阅的专用Azure VM中。在CS 与MA门户之间进行定期同步。 MA…

0

如何写出高效能TSQL – 关于索引不可不知道的事

原文地址:http://blogs.technet.com/b/technet_taiwan/archive/2015/01/23/tsql-series-0123.aspx 本文将分成五大单元,分别带您了解: 索引简介 索引基本知识 索引类型介绍 索引设计注意事项 进阶推荐   简介 TSQL是查询SQL Server的核心,而索引则是提高查询效能的主角,如要写出高效能TSQL则无可避免需搭配正确索引,因为SQL Server需透过正确索引才可以快速有效地找到与索引键值相关数据,有了正确索引SQL Server就不需要扫描数据页(data page)上每一笔数据,而在众多查询效能调校技术中,透过建立并设计正确索引算是最基本的手法 (通常来说也是最有效、最快能看到效果的),所以了解索引观念和特性,可以帮助我们在开发阶段设计规划正确索引,而且我们认为不管是开发人员或DBA都应该了解索引该如何设计,因为都有可能接收用户最直接的感受,说白话一点,每一句查询TSQL都要以最短时间响应给用户。但由于索引主题范围庞大,所以一开始我们会介绍索引基本知识、B-tree 结构等,后面介绍索引类型、案例分享及设计须注意的方向,主要是希望透过本文可以让大家快速建立正确索引。   索引基本知识 SQL Server 如何使用索引 我们都知道索引可以提高查询效能,但相对也增加新增(Insert)、删除(Delete)和更新(Update)数据处理成本,所以对整体效能来说找一个合适平衡点相当重要。 当一个数据表没有索引时,数据存放的顺序绝不是依照数据新增顺序,这是因为SQL Server Database Engine会自我处理数据储存位置,所以基本上,我们无法事先预测数据储存在数据页上是否都连续且都在同一区段中,而当一句Select送给SQL Server时,因为没有索引,这时SQL Server必须扫描整个数据表,以及该数据表的所有数据页和数据页上的每一笔数据,最后才返回用户最终所需要的数据结果集,这样的操作就称为表扫描(Full Table Scan)。 当数据表上有索引时 (假设索引设计正确),这时数据表上的数据一定会经过排序,所以SQL Server将基于该索引键值和结构来定位 (透过指针) 数据位置,简单来说只搜寻必要的数据页,而这些数据页已经包含用户最终所需要的数据结果集,这样的操作就称为索引搜寻(Index Seek)。 B-tree 索引结构 SQL Server所有索引基本上都采用B-tree结构,除了xml索引、全文检索索引(full-text)、数据行存放区索引(columnstore index)和内存优化索引(Memory-optimized indexes)不用B-tree。 xml 索引是存放在 SQL Server 底层数据表,全文检索索引是利用自己引擎来处理查德询和管理全文检索目录 (full-text catalogs),数据行存放区索引则是使用 in-memory 技术,内存优化索引则是使用 BW-tree 结构。 一个标准的B-tree结构 (图1)是由根结点(root)开始的页面,下面有一或多个中继层节点及一或多个分叶(Leaf)节点构成。…

1

Windows 10:全新一代的 Windows

微软宣布 Windows 10 将提供免费升级 揭开群组运算与全像摄影 Windows 10 装置神秘面纱 经过前一晚 Windows 10发表倒数计时,跨平台Windows即将登场 ,微软公司于今日发布了结合各类不同体验的新一代 Windows 系统,开启了更为个人化运算的新纪元,除此之外,微软也发布了两款全新装置,拓展从大屏幕到无屏幕等各类装置上的 Windows 体验。 Windows 10 将在装置上,提供一个更安全、创新与最新的体验。 Windows 10发表会在线影片回放: http://news.microsoft.com/windows10story/ Windows 10免费升级服务(附注1)将提供给目前使用Windows 7、Windows 8.1以及Windows Phone 8.1的消费者在第一年可以享受免费升级的服务。 「Windows 10的推出象征我们将进入以行动优先,云端至上(Mobile First, Cloud First)的世界,开启更加个人化运算的新世代」微软全球执行长Satya Nadella表示。「我们的目标是让目前正在使用 Windows 的 15 亿用户爱上 Windows 10,并让更多用户决定将 Windows 带回家。」 全新 Windows 10 体验: [View:~/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-91-73/Windows-10_5F00_-A-New-Generation-of-Windows.mp4:0:0] Windows 10:让计算机运算更加个人化 Windows 10的推出象征着我们将迎来更为个人化运算的新世代,这意味着以人为中心的理念将逐渐代替技术。 在这个新世代中,比起单纯让装置具有行动力,让使用经验具有行动力更重要、而且要无缝的让相同的体验跨到不同装置上。 用户应能够像与他人互动一样,用语音、手势和目光自然地与科技互动,在这样的情况下如果要提供一个值得信任的使用体验,隐私权保护就扮演着举足轻重的角色。 在活动上微软展示了Windows 10提供的多种新体验,具体包括:…

1

从 Web Server 向 Azure WebSites 迁移的利器(Migration Assistant)

原文地址:http://blogs.technet.com/b/nevin_dongs_blog/archive/2014/12/25/web-server-azure-websites-migration-assistant.aspx 将Web应用迁移到云端,常见的做法是采用IaaS模式,即创建虚拟机(Virtual Machine,VM)并在上面分别部署Web Server、Database Server、Cache Server、DNS Server等;当访问负荷增大的时候,则增加虚拟机的数量来实现伸缩。 之前曾讨论过,可以将数据库服务器(Database Server)采用Platform as a Server(PaaS)模式来提供,也有相关的迁移工具来帮助从SQL Server迁移到Azure SQL Database。 Azure网站(WebSites)是一种完全托管的平台即服务 (PaaS) 产品,便于快速高效地构建、部署并扩展企业级 Web 应用。同时,可以支持按需自动缩放(Auto-scaling),灵活支持不同时间段的并发访问负荷,特别是尖峰负荷。此外,可以显著降低运维工作量,而不必过多关注底层虚拟机、操作系统、网络、负载均衡等细节。 对于Azure网站的更多细节,可以参考:http://www.windowsazure.cn/home/features/web-site/ 可以开发ASP.NET网站并部署到Azure网站,相关步骤可参考:http://www.windowsazure.cn/zh-cn/develop/net/tutorials/web-site-intro-tutorial/ 如果将现有Web应用迁移到Azure网站,可以使用一个开源的辅助工具:Azure Websites Migration Assistant,具体可参考:http://migrate4.azurewebsites.net/ 目前支持从IIS Server迁移到Azure WebSites,其中特别提供了技术兼容性等方面的分析,例如端口绑定(Port Binding)、IIS身份认证、GAC、缓冲池等。如下图,工具将给出分析报告。 目前,这个工具只支持从IIS server到Azure WebSites的迁移辅助,而Azure WebSites还支持Java、PHP、Node.js或Python,后续期待工具能够涵盖对这些技术的支持;当然,也可以考虑参考这个工具的思路,开发适合自己需要的迁移辅助工具。

0

如何写出高效能TSQL -深入浅出SQL Server Relational Engine (含 SQL 2014 in-memory Engine)

原文地址:http://blogs.technet.com/b/technet_taiwan/archive/2015/01/16/tsql-series-0116.aspx 简介 良好的TSQL和正确索引是大幅提高查询效能最快的快捷方式,同时TSQL也是使用SQL Server的核心,任何应用程序想要和SQL Server沟通,都无法避免撰写TSQL,所以各种效能调校方法中,我们认为查询调校是最省成本、最快能感受到效果的方法 (如下图),这一系列文章将为大家介绍如何写出高效能TSQL,以及开发人员必须了解SQL Server相关基本知识和观念,这样才能活用相关技术,并发挥SQL Server无限潜能。     SQL Server 关系型引擎 SQL Server数据库引擎主要有两部分,这我们里不讨论储存引擎(storage engine)架构,而将会着重在关系型引擎。 由于SQL Server处理查德询过程步骤相当繁琐,当一句TSQL送给SQL Server时,我们须了解关系型引擎是如何工作的,因为每一句TSQL都必须透过关系型引擎分析处理,最后才会透过储存引擎执行并返回用户所需的数据结果集,理解关系型引擎不仅可以帮我们预先避开效能陷阱,同时也有助于我们减少查询调校和除错时间,下面我将说明几个处理关键步骤。 图一:SQL Server处理查询简单示意 图二:SQL Server处理查询关键步骤流程图   分析和绑定 一开始查询优化器会先确认语法正确性,如有错误将会立即返回错误讯息给用户,如果没有错误就会建立分析树并进行对象绑定 (如数据表字段是否存在、数据型别是否正确、函式是否异常..等),主要是因为 TSQL 并非程序性语言,它无法告知数据库应该用什么样正确步骤来撷取数据,所以这阶段会帮你处理基本语法优化、数据型别转换,简单来说就是会改写 TSQL,如把 between 转换为 >= and <=,型别比较不一致时,自动增加转换函数来确保数据正确性 (这就可能会大大影响查询效能), group by 位置..等,最后将输出逻辑 (操作) 查询树,后面将会依照所输出逻辑查询树步骤来一一执行。   查询优化 查询优化几乎可说是最复杂且耗时的阶段 (所以大家要有一点想象力),一开始会先确认计划快取区是否有适当的执行计划,如果没有找到适当执行计划,就会进行一般优化 (如果可以的话),然后再次从计划快取区寻找是否有适当的一般计划,如果存在就会分配相关内存并执行,这是因为不必为只有一种可能执行方法的TSQL进行完整优化,如此一来可以省下编译和建立执行计划时间,因为我们知道查询效能一部分取决于建立执行计划效率 (执行查询时间是产生执行计划时间 + 本身数据查询时间),所以查询优化器并不会寻找最佳执行计划,而是尽可能寻找最低成本 (以 CBO 为基础的 CPU、I/O 成本) 及传回结果速度最快的执行计划,如果该TSQL有达到一般计划条件的话,那么查询优化器将可不必进行完整优化而浪费不必要时间,下面我简单列出建立一般计划的情况…

0