Wednesday, August 20, 2014

Citrix announces releases of XenApp and XenDesktop 7.6

Ø  XenApp and XenDesktop 7.6 are designed to be deployed in the cloud, on-premise and in hybrid environments.
Ø  The new releases provide new bringing back features such as application pre-launch, session linger and anonymous logon.
Ø  The releases also provide new enhancements to the audio, video and graphics experience.  New high-performance graphics acceleration using GPUs provide high quality DirectX/2D rendering, an important requirement for engineers and designers.
Ø  Support for Unified Communications such as Lync Server 2013 and generic redirection of the latest USB 3.0 peripherals like webcams, headsets and Lync phones for Windows devices are perfect for contact center agents, contractors and remote workers.
Ø  Citrix is also releasing a new update to the HDX Mobile SDK. Which helps to re-architect apps for mobile operating systems, developers can customize their Windows applications to be mobile-aware and provide features that enable GPS location awareness, picture and video capture, and screen rotation re-factoring.
Ø  New enhancements to Citrix provisioning services, a widely deployed single image management feature of XenApp and XenDesktop uses commodity servers and RAM to drop the IOPS load on storage by 99 percent. This solves the storage throughput performance problem without deploying SSDs and high-end storage arrays.
Ø  XenApp and XenDesktop provide the only application and desktop virtualization solution available that meets both Federal Information Processing Standards (FIPS) compliance and Common Criteria evaluation requirements.
Ø  Security enhancements also have been made to enable granular policies over clipboard content filtering and directional control. This feature, inspired by customer requirements in the banking industry to help prevent credit card data hacking, gives IT control over whether end users can copy into – or out of – their virtual workspace.
Ø  The new Citrix Connector 7.5 for System Center Configuration Manager—developed in close partnership with Microsoft—enables administrators to use Configuration Manager to define and manage user access to virtual applications and desktops powered by Citrix.
Ø  Several features of the latest version seamlessly integrate with XenApp 6.5, including the new provisioning services, updates to Citrix Receiver, StoreFront and HDX, AppDNA, System Center Connector, monitoring consoles and more.

Ø  XenApp and XenDesktop 7.6 will be available in September 2014.

Monday, August 18, 2014

Sysprep for preparing Windows Image

Microsoft Sysprep comes handy when one needs to prepare a Windows OS for Imaging & cloning.

We all know it drastically reduced the time & effort required in spinning up new windows servers and desktops.
But the world has changed,
·         application coding no longer relies on machine’s security identifier
·         with invent of IAAS & DAAS, faster provisioning of virtual machines is the need of present

Hence, the technology of today further minimized the image preparation time further with the invent of Quickprep.

While the Sysprep operation needs several minutes to change the SID on a Windows OS as it needs to change all files on the hard disk drive, Quickprep works much faster only takes care of key things to give a cloned VM a new personality as below :

Function
QuickPrep
Sysprep
Removing local accounts
No
Yes
Changing Security Identifiers (SID)
No
Yes
Removing parent from domain
No
Yes
Changing computer name
Yes
Yes
Joining the new instance to the domain
Yes
Yes
Generating new SID
No
Yes
Language, regional settings, date, and time customization
No
Yes
Number of reboots
0
1 (seal & mini-setup)
Requires configuration file and Sysprep  
No
Yes


Limitations
·         The Quickprep tool comes with limited products like VMware Horizon View/ Tucloud DAAS and works only with Linked Clone desktop pools
A small percentage of software development still rely on the unique local SID like AV or NAC ones, for which sysprep will be a better deal

Horizon 6

      VMware announced that they're Challenging Citrix head on in the XenApp space by adding RDSH session support and published apps to VMware Horizon, all accessible via PCoIP
      VMware just entered a race that Citrix started many years ago. Yesterday VMware announced Horizon 6 Few Features includes:
o   Hybrid cloud, enabled by our acquisition of Desktone last year and now our Horizon DaaS offering, allows you to easily deploy virtual desktops on-prem, off-prem, or whatever combination suits your fancy.
o   Combining Horizon View, Horizon Mirage, and VMware Fusion, we can offer integrated and centralized desktop management across virtual, physical, and bring-your-own devices.
o   We’ve upped the ante for enterprise management with enhanced image management features in Horizon Mirage and integrations into vCenter Operations Manager, vCenter Orchestrator, and vCloud Automation Center.
o   Virtual SAN is now integrated and supported, helping to drive down storage costs while maintaining performance and SLA.
o   The biggest and most exciting part of the announcement is that Horizon View now supports application publishing.  This has been a feature request long-requested and long in the making.

      VMware has finally shipped a SBC product , SBC stands for Server-based computing aka RDSH (Remote Desktop Session Host) or RDS (Remote Desktop Services) or TS (Terminal Services).
      So why should anyone care about VMware releasing a product that has been around forever. For one, we all know VDI is not a silver bullet technology. Right now VDI adoption is teetering around 5% of total enterprise market share, and if you are in the group of orgs using it you tend to find a sweet spot of usage for about 20-30% of your organization. SBCs market is much bigger and VMware just entered it… but Citrix created it.
      The story goes that somehow in the 90s Citrix has able to secure the source code for Windows NT and they redesigned the OS to support multiple sessions on the same OS. This was typical in Unix mainframes but had never been done for Windows. Microsoft then bought the code back from Citrix and released Windows NT Terminal Services. Microsoft and Citrix spent the next decade being best of buddies.
      What VMware has done in Horizon 6 is create a true competitive product to XenApp. The reason Horizon 6 is a true competitor to XenApp is that they are the first product  that has done the  work to create a 3rd Party Protocol Provider for RDS.
      What is a 3PPP, it’s the official way to create a protocol that works with RDSH. It’s how ICA works with RDSH to bring you XenApp, or how RDP works (but RDP wouldn’t be third party). Up until now, any vendor in this space has not done the work to create a true 3PPP interface instead most products have just either used virtual channels on RDP or they’ve done some transcoding of RDP.


      How this works is that Windows talks to a graphics driver which then takes all the content being created and encodes it into a protocol. Microsoft uses its own protocol, RDP, Citrix uses ICA/HDX, VMware uses PCoIP/Blast

Friday, August 8, 2014

Windows Branch Cache

Microsoft System Center Configuration Manager (ConfigMgr or SCCM) has the option to use Microsoft’s BranchCache technology in order to enable clients to obtain content from local clients that have a current cache of the content. When a BranchCache-enabled client computer first requests content from a distribution point configured with BranchCache, the client will usually download the content and cache it in the BranchCache cache. This ConfigMgr content is then made available to other BranchCache-enabled clients on the same subnet that request it, and these clients also cache the content.

The key reasons that BranchCache is not suitable for ConfigMgr content distribution are that it:

Uses Background Intelligent Transfer Service (BITS), which has poor WAN bandwidth throttling, which is one of the key problems that most ConfigMgr-using organizations struggle with. BITS throttles based on worst-case pre-configurations that you set and bases its throttling on what it sees at the client NIC and first router. Activity at higher hops is not accounted for, leading to network congestion at those higher levels of the network
 Has very limited operating system deployment (OSD) support. BranchCache cannot be used in WinPE, and it offers no solution to the need for supporting PXE boot methods or state migration servers
 Has no centralized status reporting. You cannot readily verify or demonstrate that it is working as intended, nor can you find problems in order to correct them
 Caches content only for 28 days, though much of your ConfigMgr content will be needed for long after that, such as for OSD, patching new computers, or providing software to users as they change roles
 Is not enabled by default to run on computers running on battery power. A significant number of your computers are probably laptops, and most of the time when they’re available on your corporate network they may be in meetings or other scenarios where they are running on batteries
 Has no options to control the selection of the best (and never inappropriate) computers to serve content to peers.


To elaborate on those points respectively:
1. BITS is used by BranchCache as the transport protocol when obtaining the original content from a ConfigMgr distribution point. BITS has known limitations in both configuration and its capabilities when assessing network utilization.
a. BITS determines network utilization from the Network Adapter (NIC) of the client and usually from the router it connects to. Beyond that BITS has no awareness of the network activity levels to the distribution point and therefore is likely to aggravate network congestion on higher hops to the DP. This is a common network scenario in almost every modern enterprise network.
b. The throttling capability of BITS can only be specified by placing fixed percentage rate limits as the kbps level. This requires detailed knowledge of the network link speed end-to-end, estimating the worst case traffic usage scenario to reduce the risk of impact to other traffic, and then using that worst case scenario as a physical setting for all traffic. Even when network capacity becomes available, BITS can only utilize the set amount pre-configured for the worst case scenario and cannot make use of this spare capacity. As circumstances in a network change those settings must be revisited and requires considerable operational overhead for any sizable environment. Weekends have the same limits applied as weekdays restricting network traffic at an optimal time.
2. BranchCache has very limited support for OSD scenarios. WinPE does not include support for BranchCache. Provision of large WIM image files and driver packages that are required in the WinPE phase of an OSD build cannot be supplied using BranchCache and these large packages would require downloading at build time from a distribution point.
3. BranchCache does not generate ConfigMgr status messages, or provide any other means of reporting that can be viewed centrally from the Configuration Manager console or any other reporting interface. BranchCache only writes events to the local Windows event log. Administrators therefore cannot centrally verify the effectiveness or success of BranchCache in facilitating ConfigMgr deployments.
4. The default maximum client cache age is 28 days. This setting is applied to all content in BranchCache and content will only be removed when this age is reached. This is likely to cause the premature deletion of very large content that will require downloading again to the location after it has been removed.
5. By default BranchCache does not serve content when on battery power (for example, laptops at meetings).
a. There are NETSH and PowerShell commands to override this on Windows 8 or newer.
6. There is no weighting or similar mechanism, based on either system type or configuration options, to determine the most appropriate BranchCache system to download and serve requested content.
a. As a consequence the most appropriate client will not necessarily be used to serve content. A laptop is as likely to be selected as a desktop computer or a server.
b. Organizations may want to prioritize certain computers to be more likely to serve content, and for other computers to never serve content. As there is no mechanism to specify preferences for determining the BranchCache system allocated, this level of flexibility is not possible.
7. Not every BranchCache client has, or retains, the full package that has been requested.
a. This places increased risk that the complete amount of content requested is not available at a location when being required by subsequent client systems, and therefore there is an increased risk that duplication of content download will be necessary.
b. This is especially the case when the following occurs:
i. Multiple clients originally needed the package at once. The content BranchCache metadata is often not calculated as fast as the content is downloaded. Therefore some of the content is downloaded with BranchCache and some just with BITS.
ii. The first client that needed the package. May also suffer from that problem but possibly less so since the DP may be able to keep up with the metadata calculation more successfully.
iii. Subnets including both Windows 7 and Windows 8 clients. This causes the metadata to be calculated in two formats.
8. The BranchCache cache is entirely independent from the ConfigMgr cache, so the content must be physically stored on disk for both. The content thereby takes up twice as much disk space on each system. Nomad uses hard-links so that the ConfigMgr cache appears to have the content but the only copy is actually in the Nomad cache.
9. Microsoft does not recommend using BranchCache on subnets with 100 or more clients. See the BranchCache design guide: http://www.microsoft.com/en-us/download/details.aspx?id=2559
10. BranchCache is not offered as a Windows XP feature. Though most organizations have replaced or are replacing Windows XP machines, any that remain must download all content from a distribution point and cannot make use of the BranchCache technology.
11. ConfigMgr only offers PXE support for distribution points, and they must have WDS for PXE, so that means the DPs must be running on Windows Server. The functionality of a State Migration Point also requires a server and without this user data backups with USMT cannot be integrated into the OSD build scenarios being utilized. The net result is that BranchCache doesn’t address the core OSD issues around content management.
12. BranchCache cannot support clients located across multiple subnets. Therefore content must be downloaded once per subnet in locations where multiple subnets exist. This increases the amount of data that must be downloaded to the location and increases network utilization. In scenarios where multiple clients in multiple subnets all require the content at the same time, the limitations of BITS causes a cumulative effect as they are not aware of each other, greatly increasing the risk of causing network congestion and impacting other network traffic. Nomad has the Single Site Download feature
13. Mixed environments of Windows 7 and Windows 8 cannot work together. This increases the amount of content to be downloaded as they are not able to share content
a. Windows 8 can be configured for compatibility mode with Windows 7, however this removes the availability of new features and improvements to the Windows 8 version.
b. This is true as long as the DP is Windows Server 2012 or better. It can be overridden by turning off Windows 8 features and improvements (such as hash precalculation, or that cache retention can be increased)
14. BranchCache does not have any multicast capabilities to minimize deployments when large content must be delivered to many clients simultaneously.
15. Does not help with files less than 64KB in size. The impact of this issue will vary by package but can possibly account for about 5% of the overall package size.
16. Cache management is limited to a percentage of total disk space. Thus it will vary depending on disk size (a small 120GB SSD could have only 6 GB, for example), and could cause a user to run out of disk space if they use a large fraction of the disk (95%). The percentage can be adjusted via group policy with Windows 8, but it’s still a percentage.
17. BranchCache elections are done for every file or file segment in the package, as opposed to for the package as a whole. This could add LAN network congestion.
18. Non-domain-joined (workgroup) clients are not supported by BranchCache.
19. HTTP must be enabled for client-to-client transfers. This might be a security concern for some organizations.

BranchCache can use BITS, SMB or HTTP, for content retrieval. SMB and HTTP support seem to require Windows Enterprise version. BranchCache uses WSD (WS-Discovery protocol) for peer discovery.
BranchCache does not download files smaller than 64KB - the requesting client will receive these directly through normal BITS/SMB/HTTP transfer).

Friday, August 1, 2014

Web Scale Infra

Ø  According to Gartner, and as you know they’re always right J, by 2017 Web-Scale technology will be an architectural approach found operating in 50 percent of global enterprises, up from less than 10 percent in 2013!
Ø  The idea behind Web-Scale infrastructures is conversion, a way to combine, or integrate, multiple infrastructural components like (server) compute, storage, networking and virtualization into a single platform or appliance of some sort.
Ø  Resources are than aggregated and pooled, positively impacting performance, flexibility and overall efficiency. Management is centralized and simplified since converged infrastructures are, or should be, managed as a single entity no matter how big they get.
Ø  Web Scale computing focuses on scale-out rather than scale-up technologies and since, as mentioned, its resources are aggregated directly from the underlying hardware, workloads can be scaled up without needing to scale up individual server and or other related hardware, again, offering simplicity and ease of management.
Ø  Web Scale uses technologies like, data deduplication, data tiering, writes are being replicated, physical components are redundant, multiple times over in most cases, data gets compressed, and the list goes on. All this combined make that Web Scale technology is extremely robust. Eg: Nutanix


The best practices we once knew will soon become obsolete and known as ‘just’ practices, the way we once ‘did’ stuff. Another thing to think about is how we not only manage, but also need to support, upgrade and expand (scalability) our current infrastructures which isn’t an easy task with the hardware-centric architectures we’ve got going today.


Source: http://www.basvankaam.com/2014/06/18/what-is-web-scale-technology-and-where-does-it-come-from/