Windows Services for UNIX 3.5 白皮书
- 格式:pdf
- 大小:143.63 KB
- 文档页数:19
Dell™ PowerVault™NF100/NF500/NF600 系统重要信息注和注意注:“注”表示帮助您更好地使用系统的重要信息。
注意:“注意”表示可能会损坏硬件或导致数据丢失,并告诉您如何避免此类问题。
____________________本说明文件中的信息如有更改,恕不另行通知。
©2007Dell Inc.版权所有,翻印必究。
未经 Dell Inc. 书面许可,严禁以任何形式进行复制。
本文中使用的商标:Dell、DELL徽标、 PowerVault、PowerEdge 和 OpenManage 是 Dell Inc. 的商标;Intel、Pentium、Xeon和Speedstep 是 Intel Corporation 的注册商标;Microsoft、Windows 和 Windows Server是 Microsoft Corporation 的注册商标;UNIX是 Open Group 在美国和其它国家/地区的注册商标。
本文件中述及的其它商标和产品名称是指拥有相应商标和名称的公司或其制造的产品。
Dell Inc. 对本公司的商标和产品名称之外的其它商标和产品名称不拥有任何专有权。
2007 年 11 月修订版 A01目录支持的配置 (5)最低硬件与软件要求 (6)BIOS 和 BMC 固件 (6)硬件 RAID 和软件 RAID (7)Internet 小型计算机系统接口(iSCSI) Software Target 功能 (8)系统固件和驱动程序 (8)系统硬件 (9)支持的 Intel EM64T 功能 (9)已知问题 (10)故障排除 (18)一般故障排除问题 (19)故障排除值表 (21)排除硬件 RAID 故障 (25)您可能需要的其它说明文件 (26)索引 (29)目录34目录本说明文件提供有关在 Dell™ PowerVault™ 存储服务器上安装的Microsoft®Windows® Storage Server 2003 R2 x64 Edition(含 SP2)操作系统的重要信息。
HP Universal CMDBSoftware Version:Content Pack15.00(CP15)Discovery and Integrations Content Guide-Supported ContentDocument Release Date:January2015Software Release Date:January2015Discovery and Integrations Content Guide-Supported ContentLegal NoticesWarrantyThe only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services.Nothing herein should be construed as constituting an additional warranty.HP shall not be liable for technical or editorial errors or omissions contained herein.The information contained herein is subject to change without notice.Restricted Rights LegendConfidential computer software.Valid license from HP required for possession,use or copying.Consistent with FAR12.211and12.212,Commercial Computer Software, Computer Software Documentation,and Technical Data for Commercial Items are licensed to the ernment under vendor's standard commercial license.Copyright Notice©2002-2015Hewlett-Packard Development Company,L.P.Trademark NoticesAdobe™is a trademark of Adobe Systems Incorporated.Microsoft®and Windows®are U.S.registered trademarks of Microsoft Corporation.UNIX®is a registered trademark of The Open Group.Documentation UpdatesThe title page of this document contains the following identifying information:Software Version number,which indicates the software version.Document Release Date,which changes each time the document is updated.Software Release Date,which indicates the release date of this version of the software.To check for recent updates or to verify that you are using the most recent edition of a document,go to:https:///.This site requires that you register for an HP Passport and to sign in.To register for an HP Passport ID,click Register on the HP Support site or click Create an Account on the HP Passport login page.You will also receive updated or new editions if you subscribe to the appropriate product support service.Contact your HP sales representative for details.SupportVisit the HP Software Support site at:https://.This website provides contact information and details about the products,services,and support that HP Software offers.HP Software online support provides customer self-solve capabilities.It provides a fast and efficient way to access interactive technical support tools needed to manage your business.As a valued support customer,you can benefit by using the support website to:Search for knowledge documents of interestSubmit and track support cases and enhancement requestsDownload software patchesManage support contractsLook up HP support contactsReview information about available servicesEnter into discussions with other software customersResearch and register for software trainingMost of the support areas require that you register as an HP Passport user and to sign in.Many also require a support contract.To register for an HP Passport ID,click Register on the HP Support site or click Create an Account on the HP Passport login page.To find more information about access levels,go to:https:///web/softwaresupport/access-levels.HP Software Solutions Now accesses the HPSW Solution and Integration Portal website.This site enables you to explore HP Product Solutions to meet your business needs, includes a full list of Integrations between HP Products,as well as a listing of ITIL Processes.The URL for this website is /sc/solutions/index.jsp.ContentsChapter1:Discovered Applications5Chapter2:Discovered Operating Systems20 Chapter3:Universal Discovery IPv6Support22 Chapter4:Supported Agents26Chapter5:Universal Discovery Agent,Software Utilization Plug-In,Scanner,Scanner Scheduler,and SAI Support27 Chapter6:Store and Forward Server Support30 Chapter7:Supported Protocols31 AS400ProtocolAWS ProtocolCA CMDB Protocol32 Generic DB Protocol(SQL)33 Generic Protocol35 HP Asset Manager Protocol35 HP Network Automation(NA)Protocol36 HP SIM Protocol36 HTTP Protocol37 JBoss Protocol38 LDAP Protocol38 NetApp Protocol39 NetApp SANscreen/OnCommand Protocol39 NNM Protocol40 NTCMD ProtocolPowerShell Protocol43Discovery and Integrations Content Guide-Supported ContentRemedy Protocol43SAP Protocol44SAP JMX Protocol45Siebel Gateway Protocol45SNMP Protocol46 Troubleshooting and Limitations48 SSH Protocol48Telnet Protocol56TIBCO Protocol62UDDI Registry Protocol62Universal Discovery Protocol63vCloud Protocol65VMware Infrastructure Management(VIM)Protocol65WebLogic Protocol66WebSphere ProtocolWMI Protocol68 Chapter8:Default Ports for Supported Protocols70 Chapter9:Supported Discovery Modules and Jobs72 Chapter10:Supported Integrations82 Out-of-the-Box Integration Adapters83 Chapter11:Support for HP UCMDB Integration Service on Linux87 Chapter12:Localization88 Send Documentation Feedback89Chapter1:Discovered ApplicationsChapter2:Discovered Operating SystemsDiscovery and Integrations Content Guide-Supported Content Chapter2:Discovered Operating SystemsChapter3:Universal Discovery IPv6Support This section is an overview of Universal Discovery jobs,adapters,and protocols that support IPv6.Discovery JobsThe following discovery jobs support IPv6.IntegrationsThe following integration adapters support IPv6.ProtocolsThe following protocols support IPv6. l HTTPl NTCMDl PowerShelll SQL(Generic DB)l SNMPl SSHl Telnetl Universal Discovery Agentl WMIChapter4:Supported Agents The following agents are supported:Chapter5:Universal Discovery Agent,Software Utilization Plug-In,Scanner,Scanner Scheduler, and SAI SupportThe Universal Discovery Agent,Software Utilization Plug-in,Scanner,Scanner Scheduler,and the Software Application Library(SAI)are installed on the discovered machines.These components are supported for machines running on the following operating systems and platforms:WindowsLinuxIBMOracle SolarisHP UNIXApple MacChapter6:Store and Forward Server Support The Store and Forward server is supported on the following operating systems and platforms: WindowsLinuxChapter7:Supported ProtocolsThis section describes the credentials for the supported protocols for the Discovery and Integration Content Pack.For information about setting up protocol credentials in UCMDB,see the section about setting up the Data Flow Probe in the HP Universal CMDB Data Flow Management Guide.AS400Protocol32AWS Protocol32CA CMDB ProtocolGeneric DB Protocol(SQL)33Generic Protocol35HP Asset Manager Protocol35HP Network Automation(NA)Protocol36HP SIM Protocol36HTTP ProtocolJBoss Protocol38LDAP Protocol38NetApp Protocol39NetApp SANscreen/OnCommand Protocol39NNM Protocol40NTCMD Protocol41PowerShell Protocol43Remedy Protocol43SAP Protocol44SAP JMX Protocol45Siebel Gateway Protocol45SNMP Protocol46Troubleshooting and Limitations48SSH Protocol48 Telnet Protocol56 TIBCO Protocol62 UDDI Registry Protocol62 Universal Discovery ProtocolvCloud Protocol65 VMware Infrastructure Management(VIM)Protocol65 WebLogic ProtocolWebSphere Protocol67 WMI ProtocolAS400ProtocolAWS ProtocolCA CMDB ProtocolGeneric DB Protocol(SQL)Generic ProtocolThis protocol is intended for integrations that do not need a specific protocol.It is recommended to use this protocol for all out-of-the-box integrations,as they require a user name and password only.HP Asset Manager ProtocolHP Network Automation(NA)ProtocolHP SIM ProtocolHTTP ProtocolJBoss ProtocolLDAP ProtocolNetApp ProtocolNetApp SANscreen/OnCommand ProtocolNNM ProtocolNTCMD ProtocolSee also:the section about the Extended Shell Interface in the HP UCMDB Universal Discovery Content Guide-General Reference document.PowerShell ProtocolRemedy ProtocolSAP ProtocolSAP JMX ProtocolSiebel Gateway ProtocolSNMP ProtocolTroubleshooting and LimitationsProblem.Failure to collect information from SNMP devices.l Solution1:Verify that you can actually access information from your Network Management station by using a utility that can verify the connectivity with the SNMP agent.An example of such a utility is GetIf.l Solution2::Verify that the connection data to the SNMP protocol has been defined correctly.l Solution3:Verify that you have the necessary access rights to retrieve data from the MIB objects on the SNMP agent.SSH ProtocolParametersPrivileged Mode Properties。
统信 UOS 服务器版 V20产品⽩⽩书⽬录1.引⾔ (1)2.产品介绍 (2)3.设计原则 (3)3.1.可⾔性 (3)3.2.性能⾔ (3)3.3.安全性 (4)3.4.可伸缩性 (4)3.5.可维护性 (5)3.6.稳定性 (5)4.产品功能 (6)4.1.主要功能 (6)4.1.1.进程管理 (6)4.1.2.安全机制 (6)4.1.3.内存管理 (7)4.1.4.⾔⾔界⾔ (7)4.1.5.⾔件系统 (8)4.1.6.驱动程序 (9)4.1.7.⾔络通信 (9)4.2.技术指标 (10)4.2.1.外部环境 (10)4.2.2.安装部署 (11)4.2.3.系统运维 (11)4.2.4.软件运⾔ (12)5.产品特性 (14)5.1.具有⾔主选择权和控制权 (14)5.2.全⾔⾔持主流处理器架构 (14)5.3.稳定可靠和性能优越 (15)5.4.更好的兼容性与易维护性 (15)6.应⾔场景 (17)6.1.⾔主可控应⾔ (17)6.2.⾔络服务应⾔ (17)6.3.电⾔政务应⾔ (17)6.4.关键⾔业应⾔ (18)6.5.安全可信应⾔ (18)1.引⽬操作系统作为当下计算机硬件运⾔的必备软件,与电脑硬件的发展息息相关。
世界上第⾔台电⾔计算机ENIAC(Electronic Numerical Integrator and Computer)诞⾔时,不仅没有操作系统,甚⾔连键盘显⾔器都没有,但随着计算机技术与⾔规模集成电路的发展成熟,20 世纪70 年代中期开始出现了计算机操作系统,操作系统的出现对于计算机的⾔量普及,产⾔了⾔分积极的影响,也与计算机硬件的发展相辅相成。
操作系统对于计算机来说⾔分重要,概括的讲,它主要负责对计算机各项硬件资源的分配、调度、回收和再分配⾔作,极⾔的降低了计算机操作者对硬件资源分配的⾔预程度,使操作者更加专注于如何解决具体的问题,⾔⾔先解决好解决问题的基础环境。
InCloud Sphere 4.5 旗舰版技术白皮书V1.0浪潮(北京)电子信息产品有限公司2017 年 1 月InCloud Sphere 4.5 旗舰版技术白皮书 V1.0目录1第一章摘要 (5)2第二章InCloud Sphere 产品概述 (6)2.1InCloud Sphere 介绍 (6)2.2InCloud Sphere 架构 (8)3第三章InCloud Sphere 技术原理 (9)3.1InCloud Sphere 系统设计 (9)3.2InCloud Sphere 核心技术 (11)3.2.1CPU 虚拟化 (13)3.2.2内存虚拟化 (15)3.2.3I/O 设备虚拟化 (17)4第四章InCloud Sphere 功能原理 (19)4.1 计算 (19)4.1.1CPU 管理 (19)4.1.2内存管理 (19)4.1.3GPU 管理 (20)4.2 存储 (23)4.2.1 存储I/O (23)4.2.2 快照 (24)4.2.3存储多路径 (25)4.2.4存储读缓存技术 (26)4.3 网络 (26)4.3.1网络虚拟化架构 (26)4.3.2网卡绑定 (29)4.3.3QOS (33)4.4高可用 (33)4.4.1vMotion (33)4.4.2Storage vMotion (36)4.4.3 HA (38)4.5负载均衡 (41)4.6 监控 (44)4.6.1性能收集 (45)4.6.2配置性能图表 (46)4.6.3自动化告警机制 (46)4.7vApp (48)4.8 灾备 (49)4.8.1DR 结构 (49)4.8.2DR 工作原理 (50)4.8.3DR 故障转移 (50)4.8.4备份机制 (51)4.9 容器 (52)4.9.1Docker 介绍 (52)4.9.2InCloud Sphere 旗舰版和Docker (52)4.9.3InCloud Sphere 提供Docker 支持优势 (54)5第五章InCloud Sphere 自动化能力 (56)5.1自动化安装 (56)5.1.1自动化部署架构 (56)5.1.2自动化部署条件 (56)5.1.3自动化部署过程 (57)5.1.4应答文件 (57)5.2自动化更新 (57)5.2.1iCenter 自动检查可用更新 (57)5.2.2Hotfix 自动更新 (58)5.2.3InCloud Sphere Tools 自动更新 (59)5.2.4池滚动升级 (59)6第六章InCloud Sphere 开放性和安全性 (61)6.1XAPI (61)6.1.1XAPI 介绍 (61)6.1.2XAPI 功能 (62)6.1.3XAPI 架构 (62)6.2Introspect API (63)6.2.1Introspect API 介绍 (63)6.2.2虚拟机内存保护 (63)6.2.3预防攻击技术 (63)6.2.4虚拟机无代理保护 (64)6.2.5Direct Inspect API 防病毒架构 (64)6.2.6Direct Inspect API 防病毒的优势 (65)6.3PlugIn (65)6.3.1PlugIn 介绍 (65)6.3.2PlugIn 优势 (66)6.3.3部分PlugIn 插件列表 (66)6.4安全架构 (66)6.5SSR (67)6.5.1SSR 介绍 (67)6.5.2SSR 实现原理 (68)6.5.3SSR 技术架构 (69)6.5.4SSR 主要功能 (70)6.6与OpenStack 集成 (70)6.6.1OpenStack 介绍 (70)6.6.2InCloud Sphere 旗舰版的优势 (70)6.6.3与OpenStack 集成架构图 (71)7第七章总结 (73)8第八章缩略语 (74)1第一章摘要浪潮,着力推动中国“行业云”,致力于成为中国领先的云计算解决方案供应商,业已形成涵盖IaaS、PaaS、SaaS 三个层面的整体解决方案服务能力。
This brief applies to all Microsoft Commercial Licensing programs. Table of contentsSummary (1)What's new in this brief (1)Details (1)RDS technologies requiring RDS CALs (1)Available RDS CALs (2)Licensing Microsoft desktop applications for use with Windows Server RDS (2)Dos and don'ts of using Microsoft Office with Windows Server Remote Desktop Services: samplescenarios (3)Frequently asked questions (4)SummaryThis licensing brief helps to clarify Microsoft licensing policies for Windows Server Remote Desktop Services (RDS)and Microsoft desktop applications for use with Windows Server RDS.What's new in this briefThis brief replaces previous versions of two briefs: Licensing Windows Server 2012 R2 Remote Desktop Services andLicensing of Microsoft Desktop Application Software for Use with Windows Server Remote Desktop Services. The contenthas been combined into this single brief.DetailsRemote Desktop Services (formerly known as Terminal Services) accelerates and extends desktop and application deployments to any device, improving remote worker efficiency, while helping to keep critical intellectual propertysecure and simplify regulatory compliance. Remote Desktop Services enables virtual desktop infrastructure (VDI),session-based desktops, and applications, allowing users to work anywhere. Microsoft RDS provides threedeployment choices so that customers can have the flexibility to deploy the right type of VDI desktop for their users,all from a single platform. Customers can host either sessions-based desktop, pooled virtual machines, or personalvirtual machines.RDS technologies requiring RDS CALsMicrosoft licensing policies for Windows Server Remote Desktop Services (including the components that areincluded in Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, andWindows Server 2016) require that, in addition to a Windows Server Client Access License (CAL) (acquired eitherstandalone or through Microsoft Core CAL Suite or Microsoft Enterprise CAL Suite), you must acquire a WindowsServer RDS CAL for each user or device that (i) directly or indirectly accesses any of the RDS functionality and/or (ii) directly or indirectly accesses the server software to interact with a graphical user interface (GUI) using RDS functionality or any other third-party technology.Remote Desktop Services functionality is defined as those features or services that are running when enabling the Remote Desktop Services role and/or role service(s) in Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, or Windows Server 2016. This includes, but is not limited to, Remote Desktop Gateway, Remote Desktop Web Access, Remote Desktop Connection Broker, Remote Desktop Session Host, and Remote Desktop Virtualization Host.Note: No RDS CALs are required for up to two users to access instances of the server software for administration purposes. Available RDS CALsThe following types of RDS Server Client Access Licenses are available:RDS Device CAL: Permits one device (used by any user) to use Remote Desktop Services functionality on any of your servers.RDS User CAL: Permits one user (using any device) to use Remote Desktop Services functionality on any of your servers.RDS External Connector: Permits multiple external users to access a single Remote Desktop server. If you have multiple servers, you need multiple external connectors in addition to any required Windows Server External Connectors.You may choose to combine RDS Device CALs and RDS User CALs simultaneously with the server software. You may permanently reassign your device CAL from one device to another or your user CAL from one user to another. You may temporarily reassign your device CAL to a loaner device while the first device is out of service, or reassign your user CAL to a temporary worker while the worker is absent.Licensing Microsoft desktop applications for use with Windows Server RDSThe content below is limited to Microsoft Office per device on-premises licenses and does not include per user Online Services customer scenarios.Microsoft licenses its desktop applications on a per device basis. Per device licensing means a customer must obtain a license for each desktop on or from which the product is used or accessed. For example, when a desktop application is accessed remotely across an organization using Windows Server Remote Desktop Services, a separate desktop application license is required for each desktop from which the application is accessed.Use of Microsoft desktop applications in a Remote Desktop Services environment requires that the suite/edition, components, language, and version of the license acquired for the desktops from which the desktop application is remotely accessed matches that of the copy of the application being accessed. For example:④Product (or suite): Microsoft Office Standard 2016 and Microsoft Office Professional Plus 2016 are differentproducts (or suites). A desktop licensed for Office Standard 2016 may not remotely access and use OfficeProfessional Plus 2016.④Components: A license for a suite (for example, a Microsoft Office suite) for the accessing desktop must have thesame components as the copy of the Microsoft Office suite being remotely accessed.④Language: The English/multi-language version of the Microsoft Office suite may not be accessed remotely from adesktop, which is licensed for a single language version of the Microsoft Office suite. Likewise, remote access to a licensed copy of Microsoft Office Multi-Language Pack 2013 requires the accessing desktop be licensed for the Office Multi-Language Pack 2013.Version: Microsoft Office 2016 and Microsoft Office 2013 are different versions. You may not remotely access Microsoft Office 2016 from a desktop that is licensed for Microsoft Office 2013.Microsoft Office retail (full packaged product) and original equipment manufacturer (OEM) products released in 2007 or later do not permit network use.Windows Server 2016 is licensed under a Per Core + Client Access License (CAL) model. The Per Core + CAL model provides both user and device licensing options. Customers with more devices than users can license users rather than devices. In contrast, Microsoft desktop applications are licensed under a device-based model. This means, while user CALs permit a user to access the server software from any device in a Remote Desktop Services environment, a Microsoft desktop application license permits that user to access the application only from the desktop to which the license is assigned.Remote Desktop Services can be used by both Windows desktops and non-Windows desktops (for example, Linux PCs or thin client devices). Microsoft desktop applications must be licensed for every desktop from which they are remotely accessed regardless of whether that desktop is a Windows desktop.Do s and don't s of using Microsoft Office with Windows Server Remote Desktop Services: sample scenariosRemote Desktop Services functionality provides a rich Windows desktop experience and delivers Microsoft desktop applications such as Microsoft Office to users of hardware running earlier operating systems that are licensed for those applications. Remote Desktop Services can help you centrally manage and support deploying Microsoft Office in your organization.Note: Every device that uses Windows Server Remote Desktop Services to remotely access Microsoft Office requires a Remote Desktop Services CAL, in addition to Windows Server CAL and a Microsoft Office license. Dedicate a Microsoft Office license for every desktop on or from which you plan to use or access Microsoft Office, even if that use is only occasional. Examples of desktops that might access Microsoft Office using Windows Server Remote Desktop Services functionality include Windows-based workstations, Macintosh computers, and UNIX workstations. The servers hosting the applications do not require Microsoft Office licenses.Scenario 1: Remote use in a call centerA customer has 50 Windows-based desktops in a call center and would like to use Microsoft Office on these. Two servers running Windows Server Remote Desktop Services support using Microsoft Office on these desktops. The customer needs to acquire 50 Microsoft Office licenses—one for each desktop that accesses Microsoft Office on the servers.Even if a desktop is expected to use Microsoft Office infrequently, the customer still needs to acquire and assign a Microsoft Office license to that desktop. If 20 of these desktops never use Microsoft Office, then the customer only needs to acquire 30 Microsoft Office licenses. In addition, the customer needs RDS CALs and Windows CALs for each device or user and one or more Windows Server licenses for each server.Scenario 2: Call centers with multiple shiftsA customer has 100 Windows-based desktops in a call center and would like to use Microsoft Office on all of them using Remote Desktop Services. The workers who sit at these desktops work in three eight-hour shifts, so the 100 desktops support 300 workers. Whenever a shift change takes place, the current worker closes Microsoft Office and logs off the server so that a new worker can log on and begin running Microsoft Office. The customer needs to acquire 100 Microsoft Office licenses—one for each desktop from which Microsoft Office is used. Windows Server licenses and Windows and RDS CALs are also required. Device-based CALs may be the right option when the users outnumber the devices.Note: The number of desktops, and not the number of workers, is important to this licensing scenario.Scenario 3: Desktop licenses for employeesA customer has 40 Windows-based desktops and 30 employees who use Microsoft Office on all 40 desktops.The customer needs to acquire 40 Microsoft Office licenses. This is consistent with the per device licensing policy. Scenario 4: Laptops as secondary portable devicesA customer has 20 portable desktops (for example, laptop computers) in addition to 100 desktop devices licensed under a Select Agreement.Under Select and Open Programs, Microsoft Office licenses include secondary or portable device rights for those 20 laptops. Users may not remotely access Office software running in a Windows Server Remote Desktop Services environment from those 20 secondary, portable devices. Secondary portable device rights do not cover network use. Scenario 5: Laptops as qualified desktopsAn Enterprise Agreement customer has 20 portable desktops (for example, laptop computers) that already have Microsoft Office licensed and installed on them.Under an Enterprise Agreement, all devices should be counted as qualified desktops and separately licensed for Enterprise products (for example, Office), including those 20 portable devices. The users of these 20 portable desktops occasionally connect to a server running Windows Server Remote Desktop Services to access Microsoft Office remotely while they are using a dial-up or broadband connection. As long the 20 portable desktops are licensed for the same edition, language, and version of Microsoft Office being remotely accessed, that use is covered under the licenses assigned to those 20 portable desktops. For both the licensed desktop and the separately licensed portable desktop, Microsoft Office may be used locally or accessed remotely using Remote Desktop Services or similar functionality.Note: Do not deploy and use Microsoft Office with Windows Server Remote Desktop Services with the expectation to just count and license the greatest number of desktops from which Microsoft Office is accessed at any one time. The Microsoft Office licenses may not be shared or used concurrently for different desktops. Even if you have fewer sessions active at any given time than the overall number of desktops from which you access the software, you must still count all the desktops. Every desktop must have a license regardless of whether it is used at any given point in time.Frequently asked questions1.Do I need an RDS CAL if I am using a third-party technology like Citrix XenApp, Citrix XenDesktop, EricomPowerTerm WebConnect, Quest Virtual Access Suite, GraphOn Go-Global, and so on to directly orindirectly access the server software to interact with the GUI?Yes. An RDS CAL is required for any technology used to directly or indirectly interact with the GUI. This includes (but is not limited to) using Microsoft Remote Desktop Services or other third-party software that enablesmultiuser scenarios on Windows Server.2.What version of the RDS CALs do I need?The CAL version must correspond to the server software version it accesses. Older version of CALs cannot be used with the newer version of the server software, but newer version RDS CALs can be used with an olderversion of the server software as defined in the interoperability matrix at/wiki/contents/articles/14988.rds-and-ts-cal-interoperability-matrix.aspx.The only exception to this rule are the R2 server releases where the older CALs can sometimes work with the newer R2 release of server software. For example, Windows Server 2012 RDS CALs can be used with Windows Server 2012 R2, and there are no new Windows Server 2012 R2 RDS CALs required.3.Do I need an RDS CAL if I am not running a multiuser environment but use functionality in RemoteDesktop Services—for example, Remote Desktop Gateway?Yes. An RDS CAL is required to use any functionality included in the Remote Desktop Services role in Windows Server. For example, if you are using RDS Gateway and/or Remote Desktop Web Access to provide access to a Windows client operating system on an individual PC, both an RDS CAL and Windows Server CAL are required.4.Do I have to acquire RDS CALs if I am only remotely administering Windows Server operating systems byusing Remote Desktop for Administration?No. Up to two users may connect to the Windows Server operating system simultaneously to performadministrative functions without needing any RDS CALs. Additional administrative users need the appropriate RDS CALs.5.If I am using VMware to enable a VDI solution, do I need an RDS CAL?If the solution uses any RDS roles (Remote Desktop (RD) Gateway, RD Web Access, RD Connection Broker, RD Session Host, or RD Virtualization Host), then an RDS CAL is required.6.What are the use terms for desktop applications in a Remote Desktop Services environment (where theapplication runs on the server and not on the client desktop)?Device-based licensing means a license must be obtained for each desktop on or from which the product is used or accessed. You may not share a license for the product with another desktop or assign it to different desktops.Therefore, in a Remote Desktop Services environment, you must acquire a license for all desktops that access the product running on the server.Note: Microsoft Office retail (full packaged product) and original equipment manufacturer (OEM) products released in 2007 or later do not permit network use.7.Is there a separate desktop application licensing model for use of software with Windows Server RemoteDesktop Services?No. Use of applications with Windows Server Remote Desktop Services does not change the Microsoft per device desktop application licensing model. Each desktop on or from which the software is accessed or used requires a desktop application license.8.In addition to licensing the desktops that are accessing Microsoft Office using Remote Desktop Services,do I need to purchase a license for Microsoft Office for the server that is hosting the application for other desktops to access?No. A license is not required for the copy installed on the server.9.Can I install a retail or OEM version of Microsoft Office on a network server?Microsoft Office retail (full packaged product) and original equipment manufacturer (OEM) products released in 2007 or later do not permit network use.10.If a desktop is licensed for a Microsoft desktop application, can I use that application both locally on thedesktop and remotely using Remote Desktop Services?Yes, if that license was acquired in Commercial Licensing. Commercial Licensing desktop application licenses give the customer the right to locally install the software and to use the same software remotely from a network server using Windows Server Remote Desktop Services (or similar technology). Local installation is not aprerequisite for network use. In some cases, local installation may not be technically possible or desired.However, Microsoft Office retail (full packaged product) and original equipment manufacturer (OEM) products released in 2007 or later do not permit network use, but only locally installed software.11.If I already have a desktop license for a desktop application, what additional licenses do I need for adesktop to use the software from that desktop remotely in a Remote Desktop Services environment?In addition to the license for the desktop application, you need Windows Server and Remote Desktop Services Client Access Licenses for that desktop for remote access using Remote Desktop Services.12.I have installed Microsoft Office on a network server for access and use using Windows Server RemoteDesktop Services. I have acquired Remote Desktop Services User Client Access Licenses for each of my employees. I want my employees to be able to access Microsoft Office from any company managed desktop. What licenses are needed to properly license Microsoft Office within this environment?Because Microsoft Office is licensed through a device-based licensing model only, each desktop that is used to access Microsoft Office using Remote Desktop Services must have a separate Microsoft Office license dedicated to it. Licenses for Microsoft Office cannot be shared across desktops to support concurrent use. In addition, you may not reassign a license within 90 days of the last assignment. Furthermore, Microsoft Office retail (fullpackaged product) and original equipment manufacturer (OEM) products released in 2007 or later do not permit network use.13.I have installed Microsoft Office on a network server for access and use using Windows Server RemoteDesktop Services. I want my employees to be able to access Microsoft Office from third-party devices.What licenses are needed to properly license Microsoft Office within this environment?With active Software Assurance for Office in Commercial Licensing, you can exercise your roaming rights benefit to enable users to remotely access the Office software on a qualified third-party device, regardless of thetechnology used to access the software. Roaming rights do not permit the Office software be installed and run locally on the third-party device. Roaming rights also apply only to the primary user of a licensed device with Software Assurance coverage, and are subject to the limitation on the number of users in the base license terms.14.I have just purchased several new desktops from an OEM with preinstalled licenses for Microsoft OfficeProfessional 2016. Can I install the software on a network server and use these desktops to remotely access it? What if the copy running on the server is licensed under my Commercial Licensing agreement—does that change the answer?The answer is no in both cases. First, the OEM license does not permit access and use from a network server. Even if you are licensed under your Commercial Licensing agreement to use the software on a network server from licensed desktops, your OEM Office licenses do not permit you to access the Commercial Licensing software on the server. The OEM versions and Commercial Licensing editions of Microsoft Office are not the same. However, within 90 days of purchase, you can acquire Software Assurance coverage for your OEM licenses under your Commercial Licensing agreement. Doing so gives you rights to a Commercial Licensing Office Standard edition (please refer to the Product Terms for a more complete description of the rules related to purchasing Software Assurance for OEM software). You may use the software locally on those licensed desktops enrolled in Software Assurance or remotely from a network server (for example, using Remote Desktop Services).15.I have Office Professional Plus 2016 installed on a network server. Can I access this copy of MicrosoftOffice using Remote Desktop Services from a desktop that has Office Professional Plus 2013 installed and is covered by Software Assurance?Yes. To use Office Professional Plus 2016 in this scenario, you would need to be licensed for Office Professional Plus 2016. A desktop that is licensed for and has Office Professional Plus 2013 installed and is covered by active Software Assurance is licensed for Office Professional Plus 2016.© 2017 Microsoft Corporation. All rights reserved.This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT. This information is provided to help guide your authorized use of products you license; it is not your agreement. Your use of products licensed under your commercial license agreement is governed by the terms and conditions of that agreement. In the case of any conflict between this information and your agreement, the terms and conditions of your agreement control. Prices for licenses acquired through Microsoft resellers are determined by the reseller.。
IBM FlashSystem 5000产品白皮书亮点•提供易于购买、使用和提升的灵活性•提供可负担的企业级功能和性能•充分利用来自 IBM 的 AI、分析和区块链技术IBM FlashSystem 5010 和 5030 可提供入门级企业工作负载所需的性能、功能性和成本高效性。
若要采用人工智能(AI)、实时分析和区块链等前沿技术,企业就需要具备全新级别的IT 基础架构性能和功能,造成这种需求的原因有很多,但其中最重要的是这些技术出于本身性质的原因,都会生成且使用海量的数据。
1若要充分利用 AI、区块链以及许多其他 21 世纪的新技术,就需要部署具有广泛功能的现代化 IT 基础架构,这些功能包括智能性能优化、强大的数据降维、综合性安全和加密功能、多云架构及超低延迟闪存存储等。
对于具有小型及中型应用工作负载的环境而言,这些需求尤为难以实现,因为工作负载规模较小的组织往往 IT 预算也非常有限。
由于资金非常宝贵,因此企业在升级过时功能的同时,需要保护并扩展他们当前在 IT 基础架构方面的投资。
因此,即用即付的定价战略变得尤其具有吸引力。
数据安全必须确保。
敏捷性变得前所未有的重要,因此基础架构的灵活性和可扩展性成为了关键。
IBM FlashSystem 5000 存储系统专为解决入门级企业工作负载而设计。
这些存储解决方案专注于以适宜的定价提供一系列可随着业务发展轻松演变的企业级功能。
您甚至可以在您的所有现有系统之间扩展屡获殊荣的软件定义存储功能,以优化当前的 IT 投资,构建一个领先的多云业务平台。
IBM FlashSystem 5000一系列定价适宜的企业级存储解决方案IBM FlashSystem 系列产品可为具有入门级和中型工作负载、预算有限且希望通过数据集实现竞争优势的现代组织提供非常强大的解决方案。
FlashSystem 系列产品以基于IBM Spectrum Virtualize 技术的综合性存储服务和功能为基础,可为希望寻求发展的21 世纪企业提供功能丰富且价格适宜的存储解决方案。
Windows Services for UNIX 3.5White PaperUpdated: April 22, 2004Charlie RusselMicrosoft MVP for Server 2003 InteroperabilityAbstractMicrosoft® Windows® Services for UNIX (SFU) 3.5 provides a full range of supported and fully integrated cross-platform network services geared toward enterprise customers needing to integrate Windows® and UNIX-based environments. It allows these customers seamless access to information stored in multiple platforms, consolidates network management across platforms, and reuses UNIX applications and scripts on Windows. This white paper discusses the features and functionality of SFU 3.5 and is targeted at the system administrator, developer, or integrator of a mixed UNIX and Windows network.On This PageIntroductionNew SFU 3.5 FeaturesWhy Services for UNIX?InterixCustom Installation ChoicesUse ScenariosSummaryRelated LinksIntroductionSince its introduction in 1999, Microsoft® Windows® Services for UNIX (SFU) has played a major role for those of us trying to make Windows and UNIX networks coexist peacefully. When Windows Services for UNIX 3.0 was released in 2002, Microsoft added significant new functionality with the addition of Interix technology—a full UNIX script and application execution environment that runs as a native Windows subsystem. With the release of Windows Services for UNIX 3.5 in 2004, Microsoft improves its industry-leading interoperability toolset by adding additional internationalization support and a full set of pthread APIs within Interix to broaden its award-winning interoperability suite.With SFU 3.5, Microsoft has extended the Interix SDK to support threaded applications while updating both the utilities and APIs to improve support for internationalization. Network File System (NFS) support has been extended as well to improve authentication in native Microsoft Windows Server™ 2003 Active Directory® environments.Top of pageNew SFU 3.5 FeaturesMicrosoft has made a substantial investment in improving SFU’s performance. For example, the Interix subsystem shows improvements in all aspects of performance—ranging from 30 percent improvements in fork and exec performance, to 75 percent improvements in pipe bandwidth, to more than 100 percent improvements in file I/O and more than 150 percent in fstat latency.File I/O is now within 10 percent of the Win32 subsystem. Additional improvements in multiprocessor scalability have also been realized. There have been substantial performance improvements in the Server for NFS and Server for NIS components of SFU as well.Windows Services for UNIX 3.5 works with a broad range of UNIX and Linux platforms, using industry standard protocols and utilities. It has been explicitly tested for interoperability with Solaris 7, Solaris 8, HP-UX 11, AIX 5L 5.2, and Red Hat Linux 8.0. Windows Services for UNIX 3.5 runs on Microsoft® Windows 2000 (Professional and Server versions), Microsoft® Windows XP Professional, and Windows Server 2003.Windows Services for UNIX 3.5 adds significant new features and enhancements to the Windows Server product family and represents a major shift in how interoperability of scripts and programs is accomplished. Table 1 summarizes the major new features in Windows SFU 3.5 since SFU 2.0.Table 1. New and Enhanced SFU 3.5 FeaturesFeature DescriptionNFS Client Supports setuid, setgid and sticky bitsSupport for symbolic linksPerformance improvementsInternationalization: additional language optionsNFS Server Significant performance enhancementsSupport for active-active clustering of NFS sharesSupport for setuid, setgid, and sticky bitsPer-share handing of root and anonymous accessImproved model for mapping permissions between Windows and UNIXInternationalization improvementsSFU 3.5 Support for Windows Server 2003 Volume Shadow Copy ServiceSFU 3.5 Simplified and enhanced authentication in Windows Server 2003 Active Directory environmentsNFS Gateway Internationalization improvementsMapping Server Cluster-enabled mapping serverPerformance, security, and scalability improvementsSupport for redundant mapping serversInternationalization improvementsServer for NIS Support for MD5 encryptionScalability and performance improvementsNumerous usability and administration improvementsPassword Sync New support for setting passwords using Pluggable Authentication Model on UNIXTelnet Server Security and scalability improvementsInternet Protocol version 6 (Ipv6) supportDumb terminal support (handhelds)Telnet Client IPv6 supportInternationalizationInterix and theInterix SDKAll new to SFU 3.0Improved throughput and stabilitySingle rooted file systemSFU 3.5 Utility updates for InternationalizationSFU 3.5 pthreads support in SDKSFU 3.5 API support for InternationalizationWe’ll take a look at each of the major areas and the enhancements added since SFU 2.0, and then focus on the integration of the Interix subsystem.Top of pageWhy Services for UNIX?With the growing adoption of the Windows operating system in established UNIX environments, the need for the two platforms to interoperate has increased. Windows Services for UNIX 3.5 provides a set of additional features to Windows 2000, Windows XP, and Windows Server 2003 that allow for greater interoperability with UNIX–based systems while enabling the migration of applications originally written for UNIX and Linux to run on Windows.Windows Services for UNIX 3.5 provides a full range of supported and fully integrated interoperability components and a complete SDK that supports more than 2,000 UNIX APIs. Windows Services for UNIX 3.5 provides:Interoperability components that allow seamless integration of Windows and UNIXsystems.Manageability components that enable organizations to simplify network administration and account management across both platforms.Development components that provide a full-featured development environment thattakes advantage of UNIX-centric developmental expertise.Migration components that enable organizations to retarget UNIX applications and scripts to Windows using the Interix technology of Windows Services for UNIX, providing arobust and resource-sparing home for UNIX applications while providing a clear pathforward to the features of .NET.Windows Services for UNIX provides four compelling scenarios for the heterogeneous UNIX and Windows network that enable you to take the best advantage of both environments to simplify and manage your enterprise. The four scenarios are:Using UNIX network resources.Simplifying network administration.Simplifying account management.Taking advantage of UNIX expertise.In this section, we’ll look at the first three scenarios in greater detail. In the next section, we’ll examine Windows Services for UNIX and how it can provide better business value and better IT management across diverse environments by letting you use your UNIX-centric expertise and applications on Windows.Use UNIX Network ResourcesWindows Services for UNIX gives you four important tools that enable you to use UNIX network resources for your Windows clients and servers while also enabling your UNIX clients utilize the resources of Windows servers. These four tools are:Client for NFS. This tool enables Windows 2000, Windows XP, and Windows Server 2003 to access the resources of NFS servers on a network.Server for NFS. This tool enables NFS clients on a network to access Windows resources through NFS. The NFS Server service is now fully cluster-aware, supporting active-active clusters.Gateway for NFS. This tool enables Windows 2000 Server or Windows Server 2003 to provide seamless access to the NFS resources on a network to downstream Windows computers without any additional software installed on the Windows computers.Server for PCNFS. This tool enables Windows to act as a PCNFSD server, providing user authentication for file access to NFS servers.Management and ConfigurationThe Services for UNIX Administration Microsoft Management Console (MMC) console is used to administer the Client for NFS and Server for NFS services but not the Gateway for NFS service. To open the console, you can either launch it from the Start menu or open the Sfumgmt.msc snap-in from within an MMC console. Alternately, you can administer most NFS options from the command line. Complete command-line syntax is available from the command line by typing:nfsadmin [client | server | gw] /?Client for NFS The properties you can modify for the Client for NFS are:Authentication. The mapping server to use for authentication.File permissions. The default file access permissions. Defaults are: rwxr-xr-xPerformance. The settings for the following performance related factors (and theirdefault values):Table 2. Performance SettingsConnecting to an NFS ExportYou can connect to an NFS export in a variety of ways by using either standard Windows syntax (\\server\share) or standard UNIX syntax (server:/share). From the command line you can use the standard Windows net commands or the more UNIX-like mount command with eithersyntax. Or simply browse your Network Neighborhood in Explorer. From the command line, the following are equivalent:net use * server1:/homenet use * \\server1\home Setting Default ValueTransport Protocol UDPMount Type SoftRetries 1Timeout 0.8 secondsRead Buffer Size 32 KbWrite Buffer Size 2 Kbmount server1:/home *mount \\server1\home *Tip: When you are sure you are connecting to an NFS export, use the UNIX server:/share syntax for a faster setup of the connection.Server for NFSWindows Services for UNIX provides a robust Server for NFS tool that provides disk resources from your Windows 2000, Windows XP, and Windows Server 2003 systems to any machine on your network that supports NFS. To administer the Server for NFS, use the Windows Services for UNIX MMC console, or from the command line use nfsadmin.From the Windows Services for UNIX MMC console, you can set the following options: Table 3. Console OptionsSharesYou create shares using Windows Explorer by selecting the NFS Sharing tab from the Properties page. You can share either individual folders or entire drives. To share a folder from the command prompt, type:nfsshare sharename=drive:pathWhere drive:path is the location of the folder you want to share. As in UNIX, you can’t share a subfolder of an existing share. For this purpose, each drive letter is treated as a separate root directory. Complete command-line syntax is available from the command line by typing: nfsshare /?Share PermissionsShare permissions are set per client machine or group of machines. To set the share permissions, open the properties dialog box for the folder you are sharing, click the NFS Sharing tab, and then click the Permissions button. The default is read only for all machines with no root access and no anonymous access.File PermissionsServer for NFS uses the Windows access rights in Discretionary Access Control Lists (DACLs) to simulate the permissions that are typical in the UNIX and NFS world. The default permissions are read/write for all users.Caution: It is important to understand that there are inherently different permissions sets in the UNIX and Windows security models and that in some cases, the alignment is merely an approximation.Gateway for NFS Option Description Logging Sets she size and location of the logging file and the operations to audit. Locking Sets the grace period for locks and a list of current locks. Client Groups Groups client machines for easier setting of permissions.Server Settings Affects performance, authentication, and file name handling.Gateway for NFS is installable on server-level products only—Windows 2000 Server and Windows Server 2003. After it is installed, you use the Gateway for NFS Sharing application (Gwconfig.exe) to create gateway shares. A gateway share takes an NFS file system resource from a UNIX machine or other NFS server and maps that NFS file system to a drive letter on a Gateway server. The drive letter is then shared out to Windows clients anywhere on a network using standard Server Message Block (SMB) protocols. Client Windows computers do not require any additional software and see the gateway shares as if they reside locally on the gateway server.Start the Gateway for NFS Shares application from the Windows Services for UNIX program group or the command line. From here you can create a gateway share that will be available to all Windows clients as if it were a local share from the gateway computer. Each gateway share uses a drive letter from the gateway computer, limiting the number of shares to the maximum number of free drive letters available on the gateway computer.From the command line, Gateway for NFS shares are managed by using the Gwshare.exe utility. For details about using this utility, see Windows Help or type:gwshare /?Tip: Gateway for NFS shares are limited by the number of available drive letters on a Gateway server. However, if you need additional shares beyond this number, you can (and should) use more than one Gateway server to provide the additional shares in order to distribute the load.Server for PCNFSServer for PCNFS provides PCNFSD support. You can enter the necessary information to create users and groups by using the Windows Services for UNIX MMC that will allow Server for PCNFS to handle the authentication of NFS file resources for all NFS clients.Note: Windows Services for UNIX does not use PCNFS for authentication, and the use of Server for PCNFS is strictly to support other PCNFS clients that require a PCNFS server be available.Simplify Network AdministrationWindows Services for UNIX provides important Windows tools to enhance and simplify the administration of your network. These tools include:Telnet Client. This tool enables character and script-based remote access andadministration across a variety of platforms.Telnet Server. This tool enables character and script-based remote administration ofWindows from a variety of clients.MMC Snap-in. This snap-in enables a consistent and central management point for all Windows Services for UNIX functionality.ActivePerl. This tool enables existing and new scripts to take advantage of the Windows Management Interface (WMI) to automate network administration tasks.Telnet ClientWindows Services for UNIX provides a character-mode Telnet client that goes beyond the one included in Windows 2000 to support both stream mode and console mode. It also provides for logging and additional configuration settings (see the set command in the following table) and commands (see the send command in the following table) that make it more robust in a mixed environment.The Telnet configuration is handled from within a Telnet session by escaping to the Telnet prompt. Press ctrl + ] (right bracket) to bring up the Telnet prompt when you’ve started a Telnet session. From here you can type the following.Table 4. Telnet CommandsKey Function? Togethelpclose To close the current connectiondisplay To show the current operating parametersopen<machinename> To open a connection to a machine (you can use an IP address here as well)send To send strings to the Telnet server. The strings are sent as is, except for the following special strings:ao Send the Telnet command Abort Output to the serverayt Send the Telnet command Are You There to the serverbrk Send the Telnet command brk to the serveresc Send the Telnet escape character to the serverip Send the Telnet command Interrupt Process to the serversynch Send the Telnet command synch to the serverstatus To print basic status information about the current session quit To exit the Telnet client completelyset To set an operating parameter. Takes the following parameters:? Get help on other set optionsbsasdel Set Backspace key to be sent as the Delete keydelasbs Set Delete key to be sent as the Backspace keycrlf Set Return key to send both a carriage return and a linefeed (0x0D,0x0A)esc x Use x as the escape character to enter Telnet client prompt (default is ctrl + ])localecho Turn on local echo of characters typedlogging Enable logginglogfile filename Set file name to be the current logfilemode x Where x is console or streamntlm Turn on NTLM authenticationterm <value> Set the requested terminal emulation: ANSI, VT52, VT100, VTNTunset To unset the options set with the set commandTip: If you use the Telnet client primarily to connect to UNIX systems, set term to ANSI and NTLM off. If you frequently connect to both Windows–based and UNIX–based systems, or primarily to Windows systems, the VTNT emulation is the preferred choice, and you can use ANSI when connecting to a system that does not support VTNT.Telnet ServersWindows Services for UNIX includes two Telnet servers—the default, Windows–based Telnet server that is functionally similar to the one included with all versions of Windows since Windows 2000, and the Interix telnetd daemon, which is controlled by inetd. Only one of these Telnet servers can be enabled at a time. By default, neither Telnet server is enabled for security reasons.As installed, the Windows–based Telnet server works optimally for most installations. It accepts logons from a variety of clients, including the Telnet clients shipped with Windows 2000, Microsoft Windows NT®, and Microsoft Windows 95/98, as well as a variety of character-mode terminal clients from virtually any operating system. Additionally, it can be configured to meet specific site requirements to improve security, simplify logons, support stream or console mode, and so forth.DifferencesThe default Windows-based Telnet server should be familiar to users of Windows 2000, Windows XP, and Windows Server 2003. It is essentially the same as the server included in Windows XP Professional and Windows Server 2003 and a close relative of the one included in Windows 2000 editions. It uses the Windows Command Shell (Cmd.exe) as the default shell. This server can be started and stopped from either the Services MMC or from the Windows Services for UNIX Administration MMC (Sfumgmt.msc). See Telnet server settings below for details about the server settings and what they mean.The Interix Telnet daemon, telnetd, is normally run under the control of inetd. It uses the Interix shell as the logon shell. See the telnetd man page for information on all the options of the Interix Telnet daemon.Enabling Interix telnetdTo enable the Interix Telnet server, first stop the Windows Telnet server by using the Services for UNIX MMC to set it to manual startup or disabled. Next, from a Windows Services for UNIX shell (such as ksh), edit the /etc/inetd.conf file using a Windows Services for UNIX editor (such as vi) to uncomment the following line:#telnet stream tcp nowait NULL /usr/sbin/in.telnetd in.telnetd –iThen, from the Interix Korn shell with an account having sufficient privileges, issue the command:$ kill -1 $(ps –ef | grep inetd | grep –v grep | tr –s " " \| cut –f2 –d " ")For the detail-oriented, this one-line script finds the process ID for the inetd process, and then issues kill -1 (NOHUP) to that process, causing inetd to reread its configuration file.AuthenticationThe Windows Telnet server supports Windows NT LAN Manager (NTLM) for authentication of Windows Telnet client logons. Using NTLM allows users to be automatically authenticated to the Telnet server based on their Windows logon. This functionality makes using Telnet completelytransparent to users, while ensuring that clear text passwords don’t pass over a network. NTLM must be supported on the client side of a logon, such as with the Windows Telnet client.Note: The use of NTLM only in a mixed UNIX and Windows environment effectively locks out UNIX users from the Windows servers, because UNIX users do not have a client that supports NTLM authentication. The Interix telnet and telnetd don’t support NTLM authentication.When using NTLM logon, users are restricted to local drives on the machine they are logged on to. If they need to map network resources, they can do so by explicitly mapping with full credentials. For example:net use g: \\server\share /user:domain\usernameAdministrationThe Windows Telnet server is administered by using the Windows Services for UNIX MMC snap-in or the tnadmin program. To see the options for tnadmin.exe type:tnadmin /?The following table shows available options that can be set are.Table 5. Telnet Administration Options•Option DescriptionAuthentication Choices are NTLM and Username/Password.Auditing Sets event logging to a separate log file, or the Event Log, and sets the events to log.Server Settings Set the following options:Maximum Number of Simultaneous Connections: Default is the number of licensed connections to the server. On Professional, default is 1.Maximum Number of Failed Login Attempts: Default is 3.Map Alt key to ctrl + A: Default is yes.Telnet Port: Default is 23.Mode of Operation: Choose Console or Stream. Default is Console.Default Domain Name: Type in a domain name that is automaticallyadded to the logon user name. Default is “.”, disabling this feature.Idle Session Timeout: Specifies time until an idle session is forciblydisconnected.Terminate All Programs When Disconnecting: Toggles with the nextoption.Continue To Run Programs Started with bgjob Command: Allows jobs to continue to run after the session has ended. Default is no.Sessions Enables you to see data about the currently active sessions (such as user, domain, machine, logon date/time) and either send a message to the session or terminate it.The Interix telnetd is based on the Berkeley Software Distribution (BSD) Telnet daemon. For details of configuration options, see the man pages for telnetd.Services For UNIX MMC ConsoleWindows Services for UNIX includes a single MMC for managing everything except the Gateway for NFS. This MMC provides an easy-to-use, cohesive management interface that enables youto administer all Windows Services for UNIX machines on a network from any console. Further, because Windows Services for UNIX supports WMI, management can be fully scripted from the command line.ActiveState ActivePerl 5.8Windows Services for UNIX includes ActiveState ActivePerl 5.8 for Windows, a full-featured port of Perl 5.8 and Perl Script that runs on Windows 2000, Windows XP, and Windows Server 2003. Among a host of other improvements, ActivePerl 5.8 includes full support for the fork() command, vastly improving the portability of scripts and modules from the general Perl distribution. ActivePerl also provides full support for the Windows Scripting Host, making it an excellent tool for system administration tasks.Simplify Account ManagementWindows Services for UNIX provides important tools to help simplify the account management in a mixed Windows and UNIX network. These tools include:NIS Migration Wizard. This wizard provides the ability to move UNIX NIS source files from the NIS domain into Active Directory to consolidate account management.Server for NIS. This tool enables a Windows 2000 or Windows Server 2003 domaincontroller to act as the primary Server for NIS, integrating NIS domains with Windowsdomains and enabling administrators to manage both domains using Active Directory.Password Synchronization (two-way). This feature provides the ability to synchronize passwords for both platforms, making it easier for users to maintain one password forboth Windows and UNIX.User Name Mapping. This feature associates Windows and UNIX user names, enabling users to connect to NFS resources without having to log on to UNIX systems separately.NIS to Active Directory Migration WizardThe NIS Migration Wizard provides a simple-to-use tool that helps you to easily migrate an existing NIS environment to Server for NIS. It takes your UNIX NIS source files and migrates them into the Active Directory.You can either make the source files available to the Windows server that will be running the NIS Migration Wizard by using NFS, or you can ftp them to a local directory on the server. All your map source files should reside in the same directory. You can run the Migration Wizard more than once to migrate the files in steps, or run all your migrations as a single step. If you migrate files in steps, however, you must migrate your passwd file before you attempt to migrate either the group or shadow files that depend on it.Server for NISServer for NIS enables a Windows 2000 or Windows Server 2003 domain controller to be an NIS master server or an NIS subordinate (slave) server by integrating NIS into Active Directory. If Server for NIS is used as a subordinate server, the master server must be a Windows 2000 Server or Windows Server 2003 domain controller. A Server for NIS masterserver can support both Windows and UNIX NIS subordinate servers.Password SynchronizationThe password synchronization tool included with SFU 3.5 is a two-way synchronization utility that enables you to synchronize password changes between Windows and UNIX. Password changes can begin in either Windows or UNIX for the following:HP-UX 11iSun Solaris 7, Solaris 8IBM AIX 5L 5.2Red Hat Linux 8.0Tip: If your UNIX platform is not on this list, you can still use two-way passwordsynchronization by compiling on your platform. Windows Services for UNIX includes both source code and make files to facilitate the compilation.Two-way password synchronization uses a single sign on daemon (SSOD) that runs on the UNIX server to accept password changes from Windows. It further uses a Password Authentication Mapper (PAM), also running on the UNIX server, to pass UNIX password changes to the Windows environment.Deployment NotesIf you’re going to use the password synchronization feature of Services for UNIX, take note of the following information:Windows 2000 and Windows Server 2003 domains. When synchronizing Windows 2000 and Windows Server 2003 domains with UNIX computers, the PasswordSynchronization service must be installed and running on all domain controllers in thedomain, as well as on all UNIX computers where the desired users can change theirpassword. If you uninstall the service from one of the domain controllers, you may run into problems with the other servers.Standalone servers or workgroups. When using the Password Synchronization service to synchronize passwords between standalone or workgroup Windows computers andUNIX computers, you must install the service on all Windows computers. In this case, the password synchronization service synchronizes only the local accounts on each Windows computer with UNIX.To properly synchronize passwords between Windows systems and UNIX systems, user account names need to be exactly the same on all Windows and UNIX computers using the service. Keep in mind that unlike Windows accounts, UNIX account names are case-sensitive. In addition, all UNIX computers must be set up properly with the SSOD provided on the Services for UNIX CD. If you want to use Password Synchronization to synchronize a Windows domain with an NIS domain, you need to include the NIS master servers in the list of computers that may receive password changes. You will also need to configure your daemon on the UNIX server by making the appropriate changes to the configuration and make files to use NIS.User Name MappingThe User Name Mapping feature provides a mechanism to map the dissimilar names that can exist between the UNIX and Windows environments. User Name Mapping is used even when the names are the same in both environments, but its real strength is to enable you to map users whose names are not the same in the two environments. Given that UNIX user names。