by Contributed | Mar 19, 2021 | Technology
This article is contributed. See the original author and article here.
It’s 5 PM on Friday evening – the weekend will soon be here. You do one last sweep of your inbox before signing off when your cellphone the bat phone rings. Someone didn’t get the memo about the unwritten operational rule of IT Administration: Never make changes on a Friday. The phone itself seems terrified with every ring. A panicked voice on the other end says, “I can’t ping my VM.” Pandemonium ensues…
Today we’re going to talk about a new, free, downloadable tool that can help.
Networks are complex. There are many different vendors, with many different configurations – Even your network team might be different than your Server/HCI team. In the revelry mentioned above, everything may look the same on your hosts, but it’s hard to know if the issue is caused by the host or the physical network without being able to see the physical network configuration.
If LLDP is enabled on your switchports, it can be an easy task to quickly validate some of the physical network settings. LLDP or Link Layer Discovery Protocol is an IEEE standard (802.1AB) that allows networked devices to advertise their configuration (among other things) to neighboring devices. To Windows and Azure Stack HCI, the neighboring device is the physical switchport that its connected (via the NIC). LLDP’s Wikipedia site has a nice intro where you can learn a bit more.
With LLDP, switchports can advertise the VLAN, MTU, and DCB configuration among others information which can be critical information for Azure Stack HCI systems. However, not all switches support advertisement of the same information. Without getting into the details (which you can read more about on the Wikipedia site linked above), the switch will determine how much information you can view.
Azure Stack HCI Network Switches
To improve Azure Stack HCI reliability where we have a purpose-built OS, we have begun to require that switches support LLDP. Most importantly, we require that they support some of the “organizationally specific Custom TLVs.” That is a fair amount of jargon, but it boils down to supporting capabilities like VLAN, MTU, etc. In the picture below, you can see the Organizationally Specific TLVs (type 127) along with the MTU and PFC configuration of the switchport this NIC is attached.
Note: We intend to grow the list of required TLVs over time as we work with network vendors. Check the Custom TLVs documentation link just above for updates.
Help! I need to buy a switch for Azure Stack HCI!
We document some Network Switches for Azure Stack HCI that the vendor has verified meet the requirements – the list will grow as we hear from the various switch vendors. Talk to your Network Vendor to see if your switch meets the requirements.
Having this information at your disposal can help you answer several critical questions particularly when you want to get started on your weekend:
- Did you misconfigure your host or is it the physical network?
- Did the network engineer add the necessary configuration to the correct switchport?
- Is the switchport configuration the same on each team member?
- Is the switchport configuration the same between each cluster node?
Help! My Network Admin says LLDP is insecure!
LLDP does not require credentials to receive information but that doesn’t mean it’s insecure. LLDP allows the administrator of the network device to choose which information (TLVs), if any, is sent to neighbors with the intention that this information can be used for diagnostic purposes.
Get Started
Back to our IT hero for a moment. How can you quickly determine whether the issue is on the switch or you missed some settings on your host?
An LLDP enabled switchport will periodically (typically every 30 seconds) send messages to its neighbors, including the juicy information you may want as an IT Administrator to determine whether your physical host configuration matches that of the physical network.
Retrieving this information is traditionally a bit of a challenge, however there is a tool to make this simple.
Note: If you’re not in control of your network switches, make sure you ask your network team to enable LLDP and any “organizationally specific TLVs” that the switch supports.
Install the Module
First install the DataCenterBridging module from the PowerShell gallery. This module contains a few goodies and has been updated to include the functions to parse the LLDP data from the switch.
There are four available commands at the time of writing:
Getting the Physical Switch Information
Let’s start off by trying to get the LLDP information using Get-FabricInfo. With each of the commands you can specify the SET Switch or individual Interface names (using the InterfaceName parameter). In this case, we are specifying the SET Switch that starts with the name Converged. The cmdlet finds all the physical NICs attached the switch and looks for available LLDP messages on each interface.
At first run, it probably will not find anything. The cmdlet tells you to run Test-FabricInfo to help identify the problem.
Running Test-FabricInfo identifies a few problems that we need to resolve.
You can use Enable-FabricInfo to resolve all the problems in one shot. This will install the feature and ensure that the LLDP agent is enabled on the underlying interfaces, etc.
Note: Want to know everything this is doing? Look at the code on GitHub!
Next, run Test-FabricInfo again to determine if all the requirements are met. You can see we got a little better. Only two remaining issues; we didn’t find any LLDP packets for the interfaces in the SET switch.
Wait about 30 seconds – the typical amount of time that a switchport will send LLDP packets – and try again. If you still fail after the messages above, contact your network administrator and ensure that LLDP is enabled on the switchports connected to your team members.
If LLDP is enabled on your physical switch, you will see the following below which indicates that Test-FabricInfo found an LLDP message from the physical switch for each member of the Converged team.
Now we are ready to run Get-FabricInfo. Make sure you put the output into a variable, so you can inspect it. In this case, we add everything to the $FabricInfo variable which has an object for every team member.
You can walk the individual team members to see information collected on the Windows or HCI host (under InterfaceDetails) or the physical switch (Fabric) to which the NICs are connected.
For example, here’s a look at the IP and Subnet information on pNIC01. We collect this so it’s easy to compare to the information collected from the switch. As you can see, we have the IP Address, Subnet, VLAN, etc.
In this case, we have a virtual switch on the host and as part of the storage configuration on this system, we have a team mapped host vNIC. The IP, Subnet, etc. are being displayed from that team-mapped host vNIC. If the team member isn’t part of a virtual switch, we’ll display the configuration on the physical NIC.
Now let’s take a look at what the switch sent us and what we can learn about the physical network (as mentioned before, the information will vary based on what the switch supports):
- NativeVLAN: 1133 – Untagged traffic will be sent over this vlan
- VLANID: Info Not Provided… This includes the trunked VLANs that can be carried on this switchport. The switch below did not include this information in the packet sent to the host.
- FrameSize: 9236 – The physical NIC and virtual NICs MTU configuration should not exceed the switches value or traffic will be segmented (or in some cases dropped).
- PFC is enabled on Priority3 – Data needing lossless communication (e.g. RoCE-based RDMA) should use Priority 3.
From this information, we can determine that VLAN 711 (on the storage vNIC) is not using the native vlan, and the switch is not showing the trunked VLANs in LLDP either. This leads to two conclusions:
- We should check the switch configuration or contact our network administrator if network connectivity is not available on pNIC01 because we could not confirm that traffic is available here.
- We should ask our network administrator to find us a switch that does advertise this information so that we can identify this problem ourselves (and without ruining their weekend).
Here’s the same view but from another switch. This switch did not send the PFC information, but it does show the VLAN IDs available to the host (1, 11, 12, and 40).
From here, we can tell that VLAN 711 is not available on the physical network which is at least one obvious reason why there may not be network connectivity on this link.
Some of the other problems on the physical network that you can easily identify:
- Missing VLANs
- Misconfigured Jumbo Frames
- Misconfigured PFC settings
- Topology problems e.g. cabled to the wrong switch (check ChassisGroups for this information)
Reminder: The information displayed is dependent on the switch’s capabilities. If the switch is unable to provide us with a certain TLV, we display the text “Information Not Provided By Switch.” If you see this message, you should work with your network administrator to identify if the information can be included.
Summary
Get-FabricInfo allows you to answer several questions about the physical network configuration that may come in handy when troubleshooting diagnostic issues. Is the physical network setup as I expected it? Is the configuration the same between cluster nodes? All of this and more can be answered if your switch supports LLDP and you’re running Windows or Azure Stack HCI.
Hopefully that Friday afternoon call isn’t quite so scary anymore!
Thanks for reading,
Dan “weekend warrior” Cuomo
![Power Up Microsoft 365 with the Power Platform [M365 Meetup for Government]](https://www.drware.com/wp-content/uploads/2021/03/large-1330)
by Contributed | Mar 19, 2021 | Technology
This article is contributed. See the original author and article here.
Microsoft 365’s greatest business impact can be achieved using the Power Platform family of technologies. PowerApps, Power Automate, and PowerBI are a core part of the Microsoft 365 experience and empower both citizen developers and IT to meet the mission needs of the organization.
Microsoft PowerApps allow organizations to efficiently and effectively drive toward a zero trust security model within their existing budget and M365 services scope. Because MS PowerApps are a low code development framework, included with your government Microsoft 365 (M365) subscription, existing M365 Engineers can quickly adjust service delivery methods without starting from scratch or purchasing additional costly development tools or specialized Subject Matter Development Experts. In this session, we will focus on transforming enterprise IT service administration leveraging MS PowerApps, which allows for low level IT administration without risk of high level access and permissions.
Event Link:
Sign up for the event here!
Session 1: Power Platform Introduction
Presenter:
Steve Winward, Microsoft Technical Specialist
https://www.linkedin.com/in/stevewinward/
Session 2: Utilizing Power Platform to achieve a Zero Trust
Vamonos IT LLC (link)
Presenters:
Chris Current – https://www.linkedin.com/in/chris-current-0972941b3/
Joe Tyner – https://www.linkedin.com/in/joetyner/
Jenny Bunch – https://www.linkedin.com/in/jenny-bunch/
Dave Harrison – David Harrison | LinkedIn
by Contributed | Mar 19, 2021 | Technology
This article is contributed. See the original author and article here.
The use of virtual hostnames with SAP systems is a familiar approach to SAP customers, allowing the decoupling of actual SAP Server hostnames from the hostname referred to by the SAP instance. It provides a degree of abstraction allowing for simpler virtualization, naming conventions, hardware lifecycles, organizational policies, datacenter migrations and Disaster Recovery.
This blog post will provide step-by-step instructions on how to reliably deploy an Azure VM with the actual VM Server hostname, as well as the SAP Virtual hostname on a single network interface. These instructions only apply to Windows Operating system.
NOTE: Please note that the configuration described in this article does not apply to servers using Windows Server Failover Clustering (WSFC) which can provide high availability to SAP Database and SAP Central Services servers(A/SCS.) This configuration can be applied to SAP Application Servers and 2-tier SAP systems (Application, and SCS servers installed on a single VM.)
More detail
When migrating to Microsoft Azure, many customers choose to use a single network interface for their SAP VMs, as it simplifies automation of deployments and management. A common design misconception is that multiple network interfaces increase network throughput, however in Microsoft Azure, unlike many on-premises configurations, Azure Virtual Machines can scale network bandwidth to their potential maximum for that VM size with just a single network interface. There is no need for multiple network interfaces to scale bandwidth.
As detailed in SAP Note 2109662 – Windows returns wrong IP address as source IP however, the SAP installation will throw an error unless Windows IP addresses and the DNS registration of VM hostname and the SAP Virtual hostname are configured properly.
This configuration is detailed in SAP Note 1564275 – Install SAP Systems Using Virtual Host Names on Windows, however this blog will focus on how to accomplish this specifically in Microsoft Azure.
Technical Solution
In this blog we will use the example of an SAP App server with 1 Network Interface attached and the following configuration:
- Subnet:
- Name = App
- CIDR = 10.0.0.0/26
- Netmask = 255.255.255.192
- Default Gateway (1st IP address of subnet) = 10.0.0.1
- IP address/FQDN:
- 10.0.0.8 = sapapp.contoso.local (<- VM fully qualified domain name)
- 10.0.0.9 = sapvhost.contoso.local (<- SAP virtual fully qualified domain name)
Figure 0: A layout of what we want to achieve
First, let us look at the updates needed from the Portal.
When you are adding an additional IP configuration to the Azure NIC from Microsoft Azure portal, you can add an additional IP configuration on the Home > Network interface > “NIC Name” > IP configurations blade in the following way:
Figure 1: Open NIC configuration blade and click “Add”
Figure 2: adding second IP configuration in the add ipconfig blade
Now we move to the VM and RDP into it. The first thing you will notice once you boot-up is that, only one IP configuration is visible in the VM. The reason is that Azure DHCP, by default, assigns the primary IP configuration from the Azure NIC to the network interface within the VM. The secondary IP configurations must be manually assigned at the VM OS level.
Figure 3: Output of “ipconfig /all” on the VM
Now that we are on the VM, let us walk through the steps needed to allow us to use SAP virtual hostnames on Windows.
- Windows Servers provide a convenient capability to register each of its assigned IP addresses in DNS. This means that some of the default options allow Windows Server machines to automatically register the IP addresses of the network adapters in DNS after a server restart. To prevent this, you must unset the “Register this connection’s addresses in DNS” option for the network adapters. This setting can be found on the DNS tab of the Advanced TCP/IP Settings property window for TCP/IPv4. This is a very important step, if we do not unset the option the Windows DNS client service registers both IP addresses for the Windows host name in DNS resulting in name resolution issues.
Figure 4: Uncheck the checkbox highlighted to prevent auto registration of IP addresses.
- Make sure that the Remote registry service is enabled and running. This would be required to make changes in the registry to update the properties of the network adapters registered with DNS.
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParametersDNSRegisteredAdapters{<36 character GUID corresponding to the network adapter that TCPIP was bound to>}
- Now we add the additional IP configuration on the network card
- On the “General” tab of the TCP/IPv4 properties, change the IP address acquisition to manual. This is because, as explained above, Azure DHCP only propagates the primary IP configuration to the network adapter, and we want both the IP addresses assigned to it.
Figure 5: Set the IP addresses manually
Note: If you set this properly, you will experience a short disconnection to your RDP session and connect back. If you did not set any of the properties correctly, you will not be able to connect back until the VM is rebooted.
- In the “IP Settings” tab of the advanced settings property window, you should see the manually entered IP address.
Figure 6: the primary address should show up on the “Advanced” properties window
- Add the additional IP address by clicking “Add”. The “IP settings” tab should look like below before clicking OK.
Figure 7: After adding the secondary IP configuration on the network adapter
- Next, we set “SkipAsSource” to “True” (default is “False”) for the secondary IP Address i.e., 10.0.0.9, which we added in the above step. We do this to prevent the secondary IP address from registering in DNS automatically. If “SkipAsSource” is set to “True”, then that IP address will not be registered in DNS and will not be used for host initiated outgoing communications, unless an application specifically binds to it. The preferred way to do this is via PowerShell (as shown below).
#Get interface alias, ip addresses and the skip as source before starting
Get-NetAdapter | Get-NetIPAddress | `
Where-Object -FilterScript { $_.AddressFamily -eq "IPv4" } | `
Select-Object InterfaceAlias, IPAddress, SkipAsSource
$primaryIP = "10.0.0.8" #replace with your primary ip
$netInterface = "Ethernet 3" #replace with your network adapter name
# get all the IP addresses on the interface, filtered by IPv4 and excluding
# the $primaryIP
[array]$IPs = Get-NetIPAddress -InterfaceAlias $netInterface | ``
Where-Object { $_.AddressFamily -eq "IPv4" -and $_.IPAddress -ne $primaryIP }
# set primary IP SkipAsSource to false
Set-NetIPAddress -IPAddress $primaryIP -InterfaceAlias $netInterface -SkipAsSource $false
# set other IP addresses with SkipAsSource equal to true
Set-NetIPAddress -IPAddress $IPs.IPAddress -InterfaceAlias $netInterface -SkipAsSource $true
#check all properties are set properly
Get-NetAdapter | Get-NetIPAddress | `
Where-Object -FilterScript { $_.AddressFamily -eq "IPv4" } | `
Select-Object InterfaceAlias, IPAddress, SkipAsSource
Once we complete running the code, the output from the Get-NetAdapter command above should look like this:
Figure 8: setting “SkipAsSource” to True on the secondary IP address of the NIC
- At this point we can create the Host (A) records in DNS for the Virtual Hostnames. For the reverse lookups to work, we need to ensure the flag; “Update associated pointer (PTR) record”, is set on both the addresses.
Figure 9: Host (A) records in DNS for the server and virtual hostnames
Figure 10: setting to update the PTR records in DNS
- On the VM, we need to notify Windows that the Virtual Hostname being used is actually an alternate name for the computer. We do this by adding a new multi-string value ‘BackConnectionHostnames’ under the “HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaMSV1_0” key. You can use the below PowerShell for doing this, change the sapvhost and sapvhost.contoso.local to the virtual hostnames’ short-name and FQDN.
New-ItemProperty -Path 'HKLM:SystemCurrentControlSetControlLsaMSV1_0' `
-Name "BackConnectionHostNames" `
-Value "sapvhost","sapvhost.contoso.local" `
-PropertyType MultiString
Note: This setting would not need a server restart to work. You can complete all the steps and reboot the machine
- Now that we have notified Windows that the machine has alternate names, we need to also tell Windows to allow inbound connections which are directed to this Virtual Hostname. We do this by adding a DWord value called ‘DisableStrictNameChecking’ under the key “HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServiceslanmanserverparameters”
New-ItemProperty -Path 'HKLM:SYSTEMCurrentControlSetServiceslanmanserverparameters' `
-Name "DisableStrictNameChecking" `
-Value "1" `
-PropertyType DWord
- At this point, we can reboot the VM.
- Once the VM is back online, we can log back in and do some validations
- Let us check if the ipconfig shows both the IP Addresses. We can do this after adding the second IP on the NIC as well.
Figure 11: validating that the second IP shows up in ‘ipconfig /all’ command
- Validate that reverse lookup works for the secondary IP
Figure 12: validating that reverse lookup works for secondary IP
- Check that the DisableStrictNameChecking and BackConnectionHostnames settings are working by running “net view virtualhostname” and browsing to the virtual hostname through the command prompt. Ideally, run these from a different machine to check further.
Figure 13: checking the shares are available by running net view command
- Another good test is to open the Computer Management MMC and open the virtual hostname from Action -> Connect to Another Computer -> virtual host name. If you can browse the ‘Local Users and Groups’ and ‘Services and Applications’, it is a good sign and SAPinst should be successful.
Figure 14: Test connecting to SAP virtual hostname from MMC
- Once all the tests from above tests have succeeded, we can start with the SAP installation using the virtual hostname now by running SAPinst from an administrative command prompt and execute the following command: SAPinst.exe SAPINST_USE_HOSTNAME=<virtualname>.
Summary
To recap the configuration above, here are the 6 basic steps required on the Windows virtual machine to prep it for SAP installation using virtual hostnames with a single network interface:
- Uncheck the “Register this connection’s addresses in DNS” setting on the primary NIC
- Add a second IP address configuration through the Azure Portal, and then within the VM add the second IP address to the Network Interface’s IPv4 properties
- Follow SAP Note 2109662 – using PowerShell set the “SkipAsSource” property on the second IP address (desired outcome: first IP address à SkipAsSource=false; secondary/virtual IP address à SkipAsSource=true)
Figure 15: After setting SkipAsSource, the interface details
- 10.0.0.8 = actual VM hostname, will automatically register in DNS
- 10.0.0.9 = virtual SAP hostname, will not automatically register in DNS, we will manually create this DNS record
- Maintain the registry entries:
- HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServiceslanmanserverparametersDisableStrictNameChecking = 1 (Type: DWORD)
- HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaMSV1_0BackConnectionHostnames = FQDN short hostname (Type: Multi-string value)
(ex: sapvhost.contoso.local sapvhost <Not a space, but a carriage return between these>)
- Re-set the “Register this connection’s addresses in DNS” setting on the primary NIC
- Outcome:
- VM Primary IP Address (10.0.0.8) will register in DNS with actual VM hostname
- You must manually create an A-record for the VM secondary IP Address 10.0.0.9 and the virtual SAP Hostname
To ensure you have completed these steps correctly you can validate the configuration by:
- DNS forward lookup (e.g., “nslookup sapvhost.contoso.local”)
- DNS reverse lookup (e.g., “nslookup 10.0.0.9”)
- Browse to the sapvhost.contoso.local UNC address through either the command prompt or File Explorer.
After executing this set of steps on your VM, you are now prepared to start the SAP installation by starting SAPinst on the VM using virtual hostnames. Start SAPinst from an administrative command prompt and execute the following case-sensitive command: SAPinst.exe SAPINST_USE_HOSTNAME=<virtualhostname>.
References
by Contributed | Mar 19, 2021 | Technology
This article is contributed. See the original author and article here.
By Eric Horvitz, Chief Scientific Officer
It’s that time of year when computer science educators from across the world come together to exchange ideas at the ACM SIGCSE Technical Symposium. With the accelerating sophistication and influence of computing technologies comes a critical need: Computer science education. The work of computer science educators is essential in educating and inspiring our up-and-coming computer scientists.
It’s inspiring to see the innovative ways that the teaching of computer science is evolving. And it’s heartening to see the soaring popularity of computer science. Computer science is now considered a noble profession, much like medicine and law have been viewed over the decades. Record numbers of college students are choosing computer science as their major.
Beyond serving as a path to a career in computer science, CS education provides key pathways into professions like biomedicine, aerospace, chemistry, physics, and the social sciences—places where computing is not peripheral, but where it has become a central part of the disciplines.
With great power and influence, comes great responsibility. Today, computing advancements are framing hard questions about the influence of computing technologies on people and society, including issues around safety, privacy, civil liberties, civil rights, access to technology, and the fairness of systems. Important questions have come to the fore about the outsized influence of computing technologies on our patterns of our attention, on the information that we consume, and how we spend our time. These questions and issues are growing to become an important part of computer science education. It’s wonderful to see CS educators developing and including formal content on values, ethics, and responsibilities.
All of us can remember that moment in our life when an inner voice whispered: This is what I like doing! This is who I am. This is who I will be. Educators play such a central role for students on this path of discovery. They are not only the source of knowledge—they are the source of students’ self-knowledge, the spiritual guides behind the rising spirits. Educators play such an important role with clarity and creativity with teaching, including insightful artistry with the sequencing of concepts via curricula.
From all of us at Microsoft, I’d like to extend a huge thank you! to computer science educators across the world. Thank you for the magic you bring to the classrooms, the engaging ideas, and the way you motivate, encourage, and excite computer science students.
(From opening remarks at SIGCSE Technical Symposium)
by Contributed | Mar 19, 2021 | Technology
This article is contributed. See the original author and article here.
Gartner recently released their Magic Quadrant for 2021 Cloud AI Developer Services. Microsoft is in the Leaders quadrant and was positioned highest on the ability to execute axis. You can download a complimentary copy of the Magic Quadrant for Cloud AI Developer Services for the full report. In this post, we’ll look at why, we think, Microsoft was placed in the Leaders quadrant.
According to the report, “Gartner defines cloud AI developer services (CAIDS) as cloud-hosted or containerized services/models that allow development teams and business users to leverage artificial intelligence models via APIs, SDKs, or applications without requiring deep data science expertise.”
They specifically evaluated services with capabilities in language, vision, and automated machine learning. For Azure, this includes Azure Cognitive Services, Azure Machine Learning, and Microsoft’s conversational AI portfolio. For Power Platform, this includes AI Builder and Power Virtual Agents.
“Gartner believes that enterprise development teams will increasingly incorporate models built using AI and ML into applications. These services currently fall into three main functional areas: language, vision and automated machine learning (autoML). The language services include natural language understanding (NLU), conversational agent frameworks, text analytics, sentiment analysis and other capabilities. The vision services include image recognition, video content analysis and optical character recognition (OCR). The autoML services include automated tools that will let developers do data preparation, feature engineering, create models, deploy, monitor and manage models without having to learn data science.”
Azure AI enables you to develop AI applications on your terms, apply AI responsibly, and deploy mission-critical AI solutions.
Develop on your terms
Azure AI allows you to build AI applications in your preferred software development language and deploy in the cloud, on-premises, or at the edge. Azure provides options for data scientists and developers of all skill levels – no machine learning expertise required. See the Microsoft section of the Magic Quadrant for Cloud AI Developer Services.
Apply AI responsibly
Azure offers tools and resources to help you understand, protect, and control your AI solutions, including responsible ML toolkits, responsible bot development guidelines, tools to help you explain model behavior and test for fairness, and more. We never use your data to train our models, and we keep principles like inclusiveness, fairness, transparency, and accountability in mind at every stage of our AI research, development, and deployment. See the Microsoft section of the Magic Quadrant for Cloud AI Developer Services.
Deploy mission-critical solutions
Azure lets you access the same AI services that power products like Microsoft Teams and Xbox, and that are proven at global scale. Azure leads the industry when it comes to security, and we have the most comprehensive compliance coverage of any cloud service provider. We continue to innovate and our Microsoft Research team has made significant breakthroughs, most recently reaching human parity with image captioning. See the Microsoft section of the Magic Quadrant for Cloud AI Developer Services.
Whether you’re a professional developer or data scientist, or just getting started, we hope that you can use Azure AI services to build impactful AI-powered applications that solve complex problems and enhance customer experience.
This graphic was published by Gartner, Inc. as part of a larger research document and should be evaluated in the context of the entire document. The Gartner document is available upon request from Microsoft. Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.
Recent Comments