On-prem and on-cloud

Category archive

MS Infrastructure

Microsoft server infrastructure technologies supporting Citrix desktop virtualization and other SaaS technologies.

Understanding the Windows Server Semi-Annual Channel

in Windows Server by

Microsoft has made major changes to the way that they build and release their operating systems. The new Windows Server “Semi-Annual Channel” (SAC) marks a substantial departure from the familiar release pattern that Microsoft has established. The change has pleased some people, upset many, and confused even more. With all the flash of new features, it’s easy to miss the finer points — specifically, how you, your organization, and your issues fit into the new model.

More details can be read on this highly informational article by Altarohttps://www.altaro.com/hyper-v/windows-server-semi-annual-channel/

XenApp/XenDesktop 7.15 LTSR lab on a single machine

in Hyper-V/XenApp/XenDesktop by

Having built a powerful Windows desktop with the following configuration, I would like to share the requirements and high level deployment process for a single machine XenDesktop 7.15 LTSR lab.

Host machine configuration: 

  1. Windows Server 2016 Standard evaluation with Hyper-V server role and management tools
  2. RAM and SSD storage will be much appreciated of course, the more the better.
  3. All virtual machines have single vNIC, minimum 2 GB RAM (Hyper-V dynamic), 2vCores CPU as well as basic 40GB dynamic Hyper-V disk. The following virtual machines pre-created based on sysprepped Windows 2016 Standard template:
    1. DC01. Includes Active Directory domain services, DNS, file server (for Citrix UPM), certificate services (for Storefront SSL certificate) and DHCP (for PVS).
    2. CTX01. Includes Citrix XenDesktop 7.15 LTSR Delivery Controller, Citrix Licenser server and Citrix Storefront 3.12. Initially a demo 30-day license can be used (included by Citrix) or a new trial license can be issued from MyCitrix account website. The Citrix server roles can be consolidated except for XenDesktop VDA.
    3. VDA01. Includes Citrix XenDesktop 7.15 LTSR VDA (session machine), which can be a server or desktop OS VDA.
    4. SCVMM01. Includes System Center Virtual  Machine Manager (for use of Citrix MCS provisioning technology)
    5. PVS01. Includes Citrix PVS server (for use of Citrix PVS provisioning technology), running also PXE and TFTP services.
    6. Master01. This used as the master image for creating PVS vdisk.
    7. (Optionally) Netscaler VPX Express can be used for evaluating HDX proxy with Netscaler Gateway.

Citrix lab high level deployment process: This is based upon guidance from Citrix CTP Carl Stalhood: http://www.carlstalhood.com/xaxd/xenappxendesktop-7-15-ltsr/ 


Powershell packages, repositories and GUI apps

in Powershell by

A common question which comes up around Microsoft Powershell is how to make use of the Powershell artifacts, including the following:

  1. functions
  2. snap-ins
  3. modules
  4. DSC Resources
  5. role capabilities
  6. scripts
  7. packages

In order to manage Powershell packages, the following Microsoft Powershell resource can be used as reference: https://docs.microsoft.com/en-us/powershell/module/packagemanagement/?view=powershell-6. The two cmdlets to run initially are the find-package and find-packageprovider cmdlets.

Also the Get-Help cmdlet should be run in order to download all script-related documentation for powershell packages.

Some of the most commonly used Powershell packages nuget, chocolatey and PowershellGet.

There are a lot of useful Powershell repositories in the public Internet. One good example is the Powershell Gallery. Setting up your own Powershell internal repository inside your organization is also easy (instead of setting up a full nuget server). Step-by-step instructions can be found at: https://kevinmarquette.github.io/2017-05-30-Powershell-your-first-PSScript-repository/ .

Now when it comes to putting all the above Powershell artifacts to work, from a practical point of view sometimes it is useful to create a GUI app without coding and at the same time wrap that GUI app into a standalone executable (.exe file) which can run on any Windows system. A solution for this can come from the combined use of the following free public services:

  1. PoshGUI. Using this service you can rapidly create the GUI elements of a Powershell script and copy the GUI-related code to further be populated with GUI control events and properties logic.
  2. PS2EXE. The output code from the PoshGUI service needs to be finalized with GUI control events and properties code as well as with additional business logic code as required. Then the final .ps1 file can be converted to .exe using this Ps2EXE service. The bundled download of PS2EXE includes a usage file with instructions on how to build an .exe from an existing .ps1 file. This service comes in two flavors:
    1. With GUI support.
    2. Without GUI support (original version).

Useful tracing tools in a Windows Server environment

in Windows Server by

Useful tracing tools in a Windows Server environment

Make use of the following tools for tracing a Windows Server environment:

  • Wireshark and Network Monitor
  • SQL Server Profiler
  • SQL Server log files
  • Sharepoint, Lync and Exchange Server tracing tools
  • Setup files and log files created by applications
  • IIS Tracing and log analyzer (WIndows Server feature)
  • HTTPS analyzer plugins for browsers
  • Windows event logs
  • Windows memory dumps – Windows Action Center (Microsoft FixIt)
  • MMC
  • SysInternals process monitor and other tools
  • Powershell inventory / audit scripts

Troubleshooting Internet connectivity–Tier 1 support

in Networking by

Troubleshooting Internet connectivity–Tier 1 support

Run workflow below:

  1. Reload this web page later.
  2. Check your Internet connection. Reboot any routers, modems, or other network devices you may be using.
  3. Check your DNS settings. Contact your network administrator if you’re not sure what this means.
  4. Try disabling network prediction by following these steps: Go to Wrench menu > Options > Under the Hood and deselect “Predict network actions to improve page load performance.” If this does not resolve the issue, we recommend selecting this option again for improved performance.
  5. Try adding Google Chrome as a permitted program in your firewall or antivirus software’s settings. If it is already a permitted program, try deleting it from the list of permitted programs and adding it again.
  6. If you use a proxy server, check your proxy settings or check with your network administrator to make sure the proxy server is working.
  7. If you don’t believe you should be using a proxy server, try the following steps: Go to Wrench menu > Options > Under the Hood > Change proxy settings > LAN Settings and deselect “Use a proxy server for your LAN.”

Security Support Provider Interface (SSPI)

in Windows Server by

Security Support Provider Interface (SSPI)

Source: Wikipedia

Security Support Provider Interface (SSPI) is an API used by Microsoft Windows systems to perform a variety of security-related operations such as authentication.

SSPI functions as a common interface to several Security Support Providers (SSPs):A Security Support Provider is adynamic-link library (DLL) that makes one or more security packages available to applications.

Windows SSPs

The following SSPs are installed with Windows:

  • NTLM (Introduced in Windows NT 3.51) (Msv1_0.dll) – Provides NTLM challenge/response authentication for client-server domains prior to Windows 2000 and for non-domain authentication (SMB/CIFS).
  • Kerberos (Introduced in Windows 2000 and updated in Windows Vista to support AES) (secur32.dll) – Preferred for mutual client-server domain authentication in Windows 2000 and later.
  • Negotiate (Introduced in Windows 2000) (secur32.dll) – Selects Kerberos and if not available, NTLM protocol. Negotiate SSP provides single sign-on capability, sometimes referred to as Integrated Windows Authentication(especially in the context of IIS).On Windows 7 and later, NEGOExts is introduced which negotiates the use of installed custom SSPs which are supported on the client and server for authentication.
  • Secure channel (aka SChannel) (Introduced in Windows 2000 and updated in Windows Vista to support stronger AES encryption and ECC)  (schannel.dll) – (PCT (obsolete) and Microsoft’s implementation of TLS/SSL) – Public key cryptography SSP that provides encryption and secure communication for authenticating clients and servers over the internet. Updated in Windows 7 to support TLS 1.2.
  • Digest SSP (Introduced in Windows XP) (wdigest.dll) – Provides challenge/response based HTTP and SASLauthentication between Windows and non-Windows systems where Kerberos is not available.
  • Credential (CredSSP) (Introduced in Windows Vista and available on Windows XP SP3) (credssp.dll) – Provides SSO and Network Level Authentication for Remote Desktop Services.
  • Distributed Password Authentication (DPA) – (Introduced in Windows 2000) (Msapsspc.dll) – Provides internet authentication using digital certificates.
  • Public Key Cryptography User-to-User (PKU2U) (Introduced in Windows 7) (Pku2u.dll) – Provides peer-to-peer authentication using digital certificates between systems that are not part of a domain.


SSPI is a proprietary variant of GSSAPI with extensions and very Windows-specific data types. It shipped with Windows NT 3.51 and Windows 95 with the NT LAN Manager Security Support Provider (NTLMSSP). For Windows 2000, an implementation of Kerberos 5 was added, using token formats conforming to the official protocol standard RFC 1964

(The Kerberos 5 GSSAPI mechanism) and providing wire-level interoperability with Kerberos 5 implementations from other vendors.

The tokens generated and accepted by the SSPI are mostly compatible with the GSS-API so an SSPI client on Windows may be able to authenticate with a GSS-API server on Unix depending on the specific circumstances. One significant shortcoming of SSPI is its lack of channel bindings, which makes some GSSAPI interoperability impossible.

Another fundamental difference between the IETF-defined GSSAPI and Microsoft’s SSPI is the concept of “impersonation“. In this model, a server can switch to and operate with the full privileges of the authenticated client, so that the operating system performs all access control checks, e.g. when opening new files. Whether these are less privileges or more privileges than that of the original service account depends entirely on which client connects/authenticates. In the traditional (GSSAPI) model, a server runs under a service account, cannot elevate its privileges, and has to perform access control in a client-specific and application-specific fashion. The obvious negative security implications of the impersonation concept are mitigated in Windows Vista by restricting impersonation to selected service accounts.

Active Directory object naming

in Active Directory by

Active Directory object naming

Source: Technet


Active Directory is an LDAP-compliant directory service, which means that all access to directory objects occurs through LDAP. LDAP requires that names of directory objects be formed according to RFC 1779 and RFC 2247, which define the standard for object names in an LDAP directory service.

Distinguished Name

Objects are located within Active Directory domains according to a hierarchical path, which includes the labels of the Active Directory domain name and each level of container objects. The full path to the object is defined by the distinguished name (also known as a “DN”). The name of the object itself, separate from the path to the object, is defined by the relative distinguished name.

The distinguished name is unambiguous (identifies one object only) and unique (no other object in the directory has this name). By using the full path to an object, including the object name and all parent objects to the root of the domain, the distinguished name uniquely and unambiguously identifies an object within a domain hierarchy. It contains sufficient information for an LDAP client to retrieve the object’s information from the directory.

For example, a user named James Smith works in the marketing department of a company as a promotions coordinator. Therefore, his user account is created in an organizational unit that stores the accounts for marketing department employees who are engaged in promotional activities. James Smith’s user identifier is JSmith, and he works in the North American branch of the company. The root domain of the company is reskit.com, and the local domain is noam.reskit.com. The diagram in Figure 1.10 illustrates the components that make up the distinguished name of the user object JSmith in the noam.reskit.com domain.


Active Directory snap-in tools do not display the LDAP abbreviations for the naming attributes domain component (dc=), organizational unit (ou=), common name (cn=), and so forth. These abbreviations are shown only to illustrate how LDAP recognizes the portions of the distinguished name. Most Active Directory tools display object names in canonical form, as described later in this chapter. Because distinguished names are difficult to remember, it is useful to have other means for retrieving objects. Active Directory supports querying by attribute (for example, the building number where you have to find a printer), so an object can be found without having to know the distinguished name. (For more information about searching Active Directory, see “Name Resolution in Active Directory” in this book.)


Relative Distinguished Name

The relative distinguished name (also known as the “RDN”) of an object is the part of the name that is an attribute of the object itself — the part of the object name that identifies this object as unique from its siblings at its current level in the naming hierarchy. In Figure 1.10, in the preceding section, the relative distinguished name of the object is JSmith. The relative distinguished name of the parent object is Users. The maximum length allowed for a relative distinguished name is 255 characters, but attributes have specific limits imposed by the directory schema. For example, in the case of the common name, which is the attribute type often used for naming the relative distinguished name (cn), the maximum number of characters allowed is 64.

Active Directory relative distinguished names are unique within a specific parent — that is, Active Directory does not permit two objects with the same relative distinguished name under the same parent container. However, two objects can have identical relative distinguished names but still be unique in the directory because within their respective parent containers, their distinguished names are not the same. (For example, the object cn=JSmith,dc=noam,dc=reskit,dc=com is recognized by LDAP as being different from cn=JSmith,dc=reskit,dc=com.)

The relative distinguished name for each object is stored in the Active Directory database. Each record contains a reference to the parent of the object. By following the references to the root, the entire distinguished name is constructed during an LDAP operation. (For more information about LDAP operations, see “Name Resolution in Active Directory” in this book.)



Naming Attributes

As illustrated earlier in this section, an object name consists of a series of relative distinguished names that represent the object itself and also every object in the hierarchy above it, up to the root object. Each portion of the distinguished name is expressed as attribute_type=value (for example, cn=JSmith). The attribute type that is used to describe the object’s relative distinguished name (in this case, cn=) is called the naming attribute. If you were to create a new class in the Active Directory schema (that is, a new classSchema object), the optional RdnAttID attribute could be used to specify the naming attribute for the class. In Active Directory, instances of default objects that you create have a default mandatory naming attribute. For example, part of the definition of the class User is the attribute cn (Common-Name) as the naming attribute. For this reason, the relative distinguished name for user JSmith is expressed as cn=JSmith.

The naming attributes shown in table below are the default naming attributes used in Active Directory, as described in RFC 2253.

Object Class                                  Naming Attribute Display Name              Naming Attribute LDAP Name

user                                               Common-Name                                         cn

organizationalUnit                         Organizational-Unit-Name                       ou

domain                                          Domain-Component                                  dc

Other naming attributes described in RFC 2253, such as o= for organization name and c= for country/region name, are not used in Active Directory, although they are recognized by LDAP.

The use of distinguished names, relative distinguished names, and naming attributes is required only when you are programming for LDAP and using Active Directory Service Interfaces (ADSI) or other scripting or programming languages. The Windows 2000 user interface does not require you to enter such values.

For more information about creating new classSchema objects, see “Active Directory Schema” athttp://technet.microsoft.com/en-us/library/cc977992.aspx. For more information about using ADSI, see the Microsoft Platform SDK link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources .


Object Identity and Uniqueness

In addition to its distinguished name, every object in Active Directory has a unique identity. Active Directory is identity based — that is, objects are known internally by their identity, not by their current name. Objects might be moved or renamed, but their identity never changes. The identity of an object is defined by a globally unique identifier (GUID), a 128-bit number that is assigned by the directory system agent when the object is created. The GUID is stored in an attribute, objectGUID , that is present on every object. The objectGUID attribute is protected so that it cannot be altered or removed. When you store a reference to an Active Directory object in an external store (for example, a database such as Microsoft® SQL Server ™ ), the objectGUID value should be used. Unlike a distinguished name or a relative distinguished name, which can be changed, the GUID never changes.


Active Directory Name Formats

Several formats for providing object names are supported by Active Directory. These formats accommodate the different forms a name can take, depending on its application of origin. Active Directory administrative tools display name strings in a default format, which is the canonical name. The following formats are supported by Active Directory and are based on the LDAP distinguished name:

LDAP Distinguished Name. LDAP v2 and LDAP v3 recognize the RFC 1779 and RFC 2247 naming conventions, which take the form cn=common name, ou=organizational unit, o=organization, c=country/region. Active Directory uses the domain component (dc) instead of o=organization and does not support c=country/region. In the LDAP distinguished name, the relative distinguished names appear in order beginning at the left with the name of the leaf and ending at the right with the name of the root, as shown here:


LDAP Uniform Resource Locator (URL ) . Active Directory supports access through the LDAP protocol from any LDAP-enabled client. LDAP URLs are used in scripting. An LDAP URL names the server holding Active Directory services and the attributed name of the object (the distinguished name). For example:

LDAP://server1.noam.reskit.com/cn=jsmith,ou=promotions, ou=marketing,dc=noam,dc=reskit,dc=com

Active Directory Canonical Name . By default, the Windows 2000 user interface displays object names that use the canonical name, which lists the relative distinguished names from the root downward and without the RFC 1779 naming attribute descriptors; it uses the DNS domain name (the form of the name where the domain labels are separated by periods). For the LDAP distinguished name in the previous example, the respective canonical name would appear as follows:


If the name of an organizational unit contains a forward slash character (/), the system requires an escape character in the form of a backslash (\) to distinguish between forward slashes that separate elements of the canonical name and the forward slash that is part of the organizational unit name. The canonical name that appears in Active Directory Users and Computers properties pages displays the escape character immediately preceding the forward slash in the name of the organizational unit. For example, if the name of an organizational unit is Promotions/Northeast and the name of the domain is Reskit.com, the canonical name is displayed as Reskit.com/Promotions\/Northeast.


DNS-to-LDAP Distinguished Name Mapping

Although DNS domain names match Active Directory domain names, they are not the same thing. Active Directory names have a different format, which is required by LDAP to identify directory objects. DNS domain names are therefore mapped to Active Directory domain names, and vice versa, as described in RFC 2247.

All access to Active Directory is carried out through LDAP. LDAP uses distinguished names to provide unique names to directory objects; every object in Active Directory has an LDAP distinguished name. A distinguished name is a naming structure that consists of a string of the hierarchical components that make up the complete object. Each distinguished name component is the relative distinguished name of an object in the hierarchy, beginning with the object itself and ending with the root object in the domain tree. An algorithm automatically provides an LDAP distinguished name for each DNS domain name.

The algorithm provides a domain component (dc) attribute-type label for each DNS label in the DNS domain name. Each DNS label corresponds to the relative distinguished name of an Active Directory domain. For example, the DNS domain noam.reskit.com is translated to the LDAP distinguished name that has the form dc=noam,dc=reskit,dc=com.


Logon Names

A unique logon name is required by user security principals for gaining access to a domain and its resources. Security principals are objects to which Windows security is applied in the form of authentication and authorization. Users are security principals, and they are authenticated (their identity is verified) at the time they log on to the domain or local computer. They are authorized (allowed or denied access) when they use resources.

User security principals have two types of logon names:

SAM Account Name . A SAM account name is a name that is required for compatibility with Windows NT 4.0 and Windows NT 3. x domains. SAM account names are sometimes referred to as flat names (because there is no hierarchy in the naming, so every name must be unique in the domain). These terms serve to differentiate these names from DNS hierarchical names.

User Principal Name . A user principal name (also known as a “UPN”) is a “friendly” name that is shorter than the distinguished name and easier to remember. The user principal name consists of a shorthand name that represents the user and usually the DNS name of the domain where the user object resides, or any other designated name.

The user principal name format consists of the user name, the “at” sign (@), and a user principal name suffix. For example, the user James Smith, who has a user account in the reskit.com domain, might have the user principal name JSmith@reskit.com. The user principal name is independent of the distinguished name of the user object, so a user object can be moved or renamed without affecting the user logon name.

The user principal name is an attribute ( userPrincipalName ) of the security principal object. If a user object’s userPrincipalName attribute has no value, the user object has the default user principal name < userName >@< DnsDomainName >.

If you create no other user principal name, the user principal name suffix for a security principal is the domain in which the account is created (for example, @reskit.com). You can create additional user principal name suffixes and assign them to security principal accounts if you don’t want to use the default domain name (for example, if the DNS domain name is extremely long and hard to remember). The e-mail name can also be used as the user principal name suffix. For example, in a large organization that has many domains, a user’s e-mail address might be < userName >@< companyName >.com.

You can manage user principal name suffixes for a domain in the Active Directory Domains and Trusts console in MMC. To add or remove a user principal name suffix, open the properties for the Active Directory Domains and Trusts node. User principal names are assigned at the time a user or group is created. If you have created additional suffixes for the domain, you can select from the list of available suffixes when you create the user or group account.

The suffixes appear in the list in the following order:

  • Alternate suffixes. If you have created additional suffixes, the last one that you created appears first.
  • Root domain.
  • The current domain.

For more information about creating user principal names, see Windows 2000 Server Help.

Citrix Supportability Pack

in DaaS/MS Infrastructure/Netscaler ADC/PVS/XenApp/XenDesktop/XenServer by

Citrix Supportability Pack


The Supportability Pack is a collection of popular tools written by Citrix engineers to help diagnose and troubleshoot XenDesktop/XenApp products. The tools are cataloged by features and components to make it easier to find and use. Early versions of the Pack serves as a launch pad for efforts to raise awareness, improve accessibility, and promote use of internal troubleshooting tools. In subsequent updates of this pack the spotlight will shift to creation of new tools based on prevalent customer scenarios and your feedback.
Note: The tools in this pack are not intended to replace system administration features that XenDesktop/XenApp provides for day-to-day system management. This collection of tools are specialized utilities for advanced troubleshooting in very specific areas.

Revision History

  • v1.2.1
    • Updated the following tools in the Pack to their latest version: Port Check Utility, Receiver Diagnostics Tool, Receiver Cleanup Utility, Scout and UPS Print Driver Certification Tool.
  • v1.2
  • v1.1.5 – CDF Control tool is updated to the latest version.
  • v1.1.4 – Scout tool is updated to the latest version.
  • v1.1.3 – All individual zip files in the download package have been unzipped, plus some minor revision of tools.


  1. All the tools are intended for the Microsoft Windows platform.
  2. Specific pre-requisites will vary from tool to tool. The included README contains links to the documentation (CTX article) for each tool where you can learn about tool-specific requirements.
  3. You will need Web access to lookup tool-specific Support documentation (CTX article) even though the tools are downloaded and saved in a local folder.

Installing Supportability Pack

1. If you have an older version of Supportability Pack on your system, e.g. v1.1.x, we recommend you completely remove the existing Supportability Pack including all tools and files, before downloading the new v1.2.x version. Since v1.2.x provides a new Updater utility, you can use it to keep all tools up to date in the future.

2. Unzip the Supportability Pack v1.2.x zip package into a local folder of your choice.

3. Open the README.HTML file with any web browser and begin exploring the tools catalog.

4. Each tool is in its individual folder inside the local directory Tools.

5. The Updater SupportabilityPackUpdater.exe is in the same directory as README.HTML. Use “SupportabilityPackUpdater.exe /help” to get more info about how to use it.


How to Use the Supportability Pack

The Pack can be extracted to local drive, portable drive, USB stick, etc. Once the Pack is extracted please open the README.html in any browser to begin exploring the catalog. You can review the entire set of tools or see a filtered list based on feature or component. All the listed tools are placed into the local folder Tools with its own individual subfolder. The README.html also contains URL links to the Support documentation (CTX article) for each tool where you can learn more about them.

If needed, you can directly access a tool by going into its individual subfolder. However, we don’t recommend moving or renaming the tools and related files and folders.

Security Permissions Required by Supportability Pack

You will need to appropriate privileges to download and unzip the Supportability Pack to a local folder. Please see documentation (CTX article) for each tool for any tool-specific Security permissions.

Data Modified by Supportability Pack

No data is modified when unzipping the Supportability Pack. Once unzipped the Supportability Pack will write a number of HTML documentation files along with a zip files of all the tools in the TOOLS folder. No other system changes are made.

Uninstalling Supportability Pack

The Supportability Pack can be removed by deleting the local folder where it was extracted.  Additional steps may be necessary to uninstall some tools based on their specific requirements.  Please refer to the relevant Support documentation (CTX article) for the specific tool to learn more.

Source: https://support.citrix.com/article/CTX203082

SQL Server PowerShell Overview

in Powershell/SQL by

More details at http://technet.microsoft.com/en-us/library/cc281954%28v=sql.105%29.aspx

SQL Server 2008 introduces support for Windows PowerShell. Windows PowerShell is a powerful scripting shell that lets administrators and developers automate server administration and application deployment. The Windows PowerShell language supports more complex logic than Transact-SQL scripts, giving SQL Server administrators the ability to build robust administration scripts. Windows PowerShell scripts can also be used to administer other Microsoft server products. This gives administrators a common scripting language across servers.

SQL Server provides two Windows PowerShell snap-ins that implement:

  • A SQL Server provider, which enables a simple navigation mechanism similar to file system paths. You can build paths similar to file system paths, where the drive is associated with a SQL Server management object model, and the nodes are based on the object model classes. You can then use familiar commands such as cd and dirto navigate the paths similar to the way you navigate folders in a command prompt window. You can use other commands, such as ren or del, to perform actions on the nodes in the path.
  • A set of cmdlets, which are commands used in Windows PowerShell scripts to specify a SQL Server action. The SQL Server cmdlets support actions such as running a sqlcmd script containing Transact-SQL or XQuery statements.
Go to Top