IT Infrastructure | Virtualization | Application Delivery | Networking | Storage


by 2 Comments

My first FAIL!

There’s nothing quite like that short lived ‘buzz’ after walking out a tech exam with a big phat PASS! Back in January however, I came out of the examination room with what’s best described as a ‘stunned stagger’ in place of the more familiar ‘victory swagger’ 🙂

What beat me? Office 365, 70-347 – Enabling Office 365 Services. I only missed it by 2 questions but it may have well have been 10 with the amount of guess work I was doing. I knew I wasn’t fully prepared but I thought I had enough knowledge to scrape on through. I felt this way a couple of times in the past and it always worked out, but this time it didn’t. My Powershell skills are pretty decent but my practical experience around the Skype for Business and SharePoint online modules let me down… not to mention Staffhub, I got a few questions on that and I was like “What’s a Staffhub?”… yeah, oh dear…

I managed to comfortably pass 70-347 at the end of March and what a relief that was. Not only did I get the certification, but I can now avoid that walk of shame leaving the test centre, which was quite painful first time around.

It will come as no surprise but all it needed was some time and effort. I ran up a couple of O365 E3 trials and got stuck into the practical, making sure I addressed my weaknesses, and got on top of the newer apps and services. I also used the free tutorials by Platform Scholar which I highly recommend for anyone who is thinking of going for the O365 MSCA. Here’s a link to the channel:

https://www.youtube.com/channel/UCJuU1BAaEeVMTSopVX05Q9g

They are updated pretty regularly and cover both 70-346, Managing Identities & Requirements and 70-347 and Enabling Office 365 Services, which combined give you the MCSA. More detail on that here:

https://www.microsoft.com/en-gb/learning/mcsa-office365-certification.aspx

I’m taking this failure as positive, as it has eradicated any complacency I had lurking in the system, which should help with the other exams I have lined up for this year. A bunch of Citrix renewals, Architecting Azure Solutions and Windows Server 2016. The fun and learning never ends…

Good luck to anyone taking the exam and feel free to ask any questions, cheers

 


by Leave a comment

VMUG Scotland… A first for me…

It’s funny… there was a period of my career where VMware was a main focus and I’d spend countless hours implementing, supporting and upgrading the platform but I never found myself attending a VMUG. This wasn’t through lack of interest by any means… just busy, I guess.

Now that I’ve gone stagnant with the technology and it’s no longer on my radar I find myself at my first VMUG today, go figure! 🙂

The event was held in Edinburgh’s elegant Surgeon’s Hall which proved to be a bit of a maze but I managed to make registration with a minute to spare. Unfortunately I couldn’t hang around all day but the the first half was great. Very well organised with great content around what’s new and in the pipeline for vSAN, NSX and Data Recovery.

My highlight of the day was Chris Wahl’s talk on his journey to full stack engineering. I’ve been an avid listener of the Datanauts podcast since it began on PacketPushers a couple of years back and if I’m honest, seeing his name on the lineup was a clincher for registering  and taking the train through to Edinburgh. Chris talked through his life in tech, from his early beginnings of hacking games from 8 years old, through to his tough gigs like saving us all from the Y2K bug then ‘busting’ his way through many of the IT silos – giving us great insights into the wins and pitfalls of his career.

I was fortunate enough to grab some of his time, sip some coffee and talk some tech 🙂

wahl

For anyone that’s not been to a Scottish VMUG and has an interest in the technology I’d definitely recommend it. A well organised event with plenty of friendly people to mingle with and learn from.

Get signed up here:

https://www.vmug.com/Join

And be sure to subscribe the Datanauts podcast:

http://packetpushers.net/datanauts-podcast/

 


by Leave a comment

How to install the Kaseya VSA Agent on a non-persistent machine

Deploying Kaseya VSA agents to provisioned workstations and servers from a standard image can be a challenge. Using the typical methods result in duplicate GUID’s due to the nature of the technology making it impossible to accurately monitor and report on these types of machines.

The following procedure has been tried a tested (successfully) numerous times on Citrix VDI/SBC environments leveraging Provisioning Server and Machine Creation Services. That being said, the process should work on other systems that are non-persistent providing they have a persistent volume where the application files can be placed.

The term ‘Target Devices’ used throughout this process is what provisioned desktops and servers are called in Citrix Provisioning server. If you are not familiar with Citrix Provisioning server, think of these as being your non-persistent machines that the image is being delivered to.

  1. The first thing we want to do is create an Organisational Unit (OU) where your update / maintenance target device(s) will live.
  2. Apply a GPO to the maintenance Organisational Unit (OU) which will stop Kaseya communicating with the master server.
  3. Create a new agent package configured to install the agent on the persistent drive, typically, the ‘writecache’.
  4. Create a new version and open the master image / vDisk in maintenance mode (read/write)
  5. Manually install the package onto the new version making sure the GPO is working which prevents communication with Kaseya (Stopping the agent from connecting to the Kaseya master server which in turn updates the KaseyaD.ini file)
  6. Once installed, go into the install location on the persistent drive and scoop out a copy of the folder labelled with the agent ID, this is typically found inside ‘Program Files (x86)\Kaseya’ (You will need this for later)
  7. Stop the Kaseya services.
  8. Delete the following 3 registry keys:
    Kaseya-Agent-PVS
  9. Perform typical cleanup tasks and shutdown the machine.
  10. Promote new version to Test/Production.
  11. Place the folder that was copied in step 3 into the persistent drive on all target devices that are provisioned from the master image / vDisk (This should be placed in the directory Kaseya expects to find it as configured in step 1 (Regedit can be used to confirm this)
  12. Reboot your target devices.

That’s it… you’re done. Provisioned / non-persistent machines should now report into the Kaseya master server with a unique GUID as do standard machines.

If Kaseya services fail to start on target devices it’s likely due to the application files being in the wrong path on the persistent drive. Confirm the application files are where the should be according to the registry.

Very keen to hear how you go. Feedback welcome, thanks

 

 

 


by Leave a comment

Powershell for all as it goes Open Source

First off, kudos to that ‘Technical Fellow’ Jeffrey Snover and his team in the Powershell division at Microsoft. Powershell is a management framework for task automation and a must for any serious IT Professional working with the Windows platform. As this blog title suggests, Microsoft open sourced it and as of last week it’s readily available for Linux and Mac OSX. This is very exciting IT news, probably the best I’ve heard in the last 6 months but what does it actually mean?

With every new technology in the IT space comes a plethora a new capabilities and options to further streamline operations and simplify what we do and how we do it while increasing the ROI… Yeah, that’s what we aim for but new options and technologies bring a heap of new challenges too. I recently read that 1 in 3 VM’s in Azure are running Linux, yes Linux! When you stop and think for a minute, it’s not very surprising. Businesses today, particularly the enterprise run on various cloud providers, operating systems and platforms. I like the way Microsoft has gone more customer focused since our man Satya Nadella took control of the ship, it’s a smart move and a sound way for Microsoft to stay relevant as we move towards true Digital Transformation. Open Sourcing Powershell is a great move to help manage and make these various platforms work together.

If you are new to Powershell, or have been more of a ‘Linux guy’ and would like to learn more I highly recommend “Learn Windows Powershell in a Month of Lunches” by Don Jones and Jeffrey D. Hicks. There are also approx 100 short videos freely available on Youtube by Don Jones.

https://www.manning.com/books/learn-windows-powershell-in-a-month-of-lunches-second-edition

In order to get Powershell up and running on your Mac OSX or Linux machine you just need to run the installer, open the terminal and drop in to Powershell:

linuxlab

All cmdlets will work as they do on Windows, there’s also some new modules like ‘new-cronjob’ for OS specific task management but these need to be loaded separately into the relevant Powershell directories, then imported as you would do with a standard snappin or module.

You can find all the detailed information with regard to versions and getting started on the GitHub page here:

https://github.com/Microsoft/PowerShell-DSC-for-Linux

I’ll leave you now with a very interesting technical introduction and demo by the team at Microsoft along with some great guests like Alan Renouf from VMware and AWS showcasing their support and appreciation of the capabilities on their respective platforms.

Thanks for reading, feel free to share.


by Leave a comment

Arcserve RHA Reverse Scenario (Failback) Considerations & Preperation

Arcserve RHA (Replication & High Availability) is one of the core products within the Arcserve suite. At a glance, the Arceserve solution is made up of 3 key components:

  • Arcserve Backup – Tape Backups
  • Arcserve UDP / D2D – Disk to Disk
  • Arcserve RHA – Replication & High Availability

Having years of experience operating & integrating a range of backup solutions including Commvault, TSM, Symantec & Storagecraft, I’m no stranger to the trials, tribulations, pain points and chores of the ‘backup guy’. With all that in mind, I have found Arcserve to be a simple and robust solution that’s fit for the enterprise.

I must say at this point, if you have not used Arcserve in many years and happen to be in the market for a new backup / HA solution, it’s worth a review as a lot has changed. I mention this as some of my clients who are now in love with the product didn’t have the fondest of memories from back in the day when its was part of Computer Associates.

In this this article, I will highlight a couple of a challenges I recently came up against with RHA, particularly the failback process (Reverse Scenario). These potential challenges are subject to environment variables that could affect many implementations of the solution and only really come to light in a failback scenario. I thought it would be good to share this experience with the findings and resolutions so that other engineers can consider this at build time and quickly rectify the issues when a failback is required whether it be test or the real deal.

Environment Overview:

  • Replication of 25 business critical servers from Head Office to Co-location
  • Connected via 1Gb dark fibre
  • Single backup (UDP/RHA) virtualized host with directly attached storage array (Data Centre / Colo)

RHA - Overview

I have weekly automated testing in place using RHA ‘Assured Recovery’. This boots the replicated VM’s to confirm they start without issue, I also configured a private network so that further testing at the application layer could be carried out manually on a regular basis. This process is none disruptive as the production servers remain online and are unaffected. Detailed, inbuilt reporting provides and an insight to the protected servers and confirms that they would, or would not correctly failover over in a production incident. In this case the reports and regular manual testing were solid. Happy days… It’s also worth noting we successfully completed some live testing (failover & failback) using non critical VM’s during the implementation and test phase.

The Problem:

Following a storage failure in head office (Primary Data Centre), I was forced to initiate a failover of the affected VM’s residing on the failed LUN. This included a few Citrix Xenapp Application servers and Microsoft Exchange. The failover worked as expected, all affected services were online and fully operational within 15 minutes. Well within the 1 hour SLA.

Once I confirmed that all of the affected VM’s were running and stable on Colo infrastructure I got the primary storage issue resolved. This took a day or so but when the LUN was reprovisoned I was ready to failback. This is when some problems started to arise. The smaller VM’s, that being Xenapp Application servers were in sync using RHA and ready to failback within 4 hours, this was 6 servers with 80GB OS volumes. However, Exchange was taking much longer to sync, it was a bigger VM but something wasn’t adding up. There was around 500 mailboxes on the server with a total size of around 1TB. Baring in mind that the link back to the production system was 1Gb fibre, I would have expected the resync to complete within around 4 hours. Technically speaking, it’s possible to push 1TB over a 1Gb link in 124 minutes but I was making allowances for the other RHA and UDP traffic which would be consuming a fair bit.

After taking a closer look at the Exchange RHA scenario I noted that it was only getting 3MBps throughput on the resync. This was destined to fail as the recovery process uses a BMR boot image that leverages WinPE. If you are unaware, WinPE has a 72 hour limit before initiating a compulsary reboot. If I let the scenario continue it would take 89 hours to resync meaning it would be unable to complete due to the interruption of the forced WinPE reboot. This posed a problem, even if I manage to resolve the throughput issue for this particular incident, I have other servers in the environment hosting seismic data that are up to 25 TB in size.

In the next section I’ll show how to resolve both issues, those being;

  • RHA Resync / throughput issue
  • WinPE 72 hour reboot issue

Solution

RHA Resync / throughput issue

After restarting the RHA scenario a handful of times I found the poor throughput persisted, I had a dig through the logs to find some references to the RHA autotune function which detects the quality of the LAN/WAN link based on a PING check / RTT delay. Anything below 50Ms is considered to be on a LAN / high performing network, anything above 50Ms is deemed to be a WAN link. There is also a default TCP SendRecieve Window size of 256K, this is not auto-sized by the application but it can be manually set to improve performance. This is the TCP chunk size of the buffer on the sending side, the data will be buffered until the receiving side returns an acknowledgement.

In this case the link was considered poor due to the high latency and poor bandwidth measurements. The link was still being utilised for incremental disk backups and replication traffic. I revisited the logs and confirmed that each of the autotune calculations were initiated at a time where there was a lot going on which was the cause of the skewed estimates.

To remedy this I manually set the TCP chunk size to 512k and decreased the TCP streams to 1. This can be done on the following configuration page and configuration file:

Edit Number of streams: 

as2

Edit TCP buffer size: 

as1

WinPE 72 hour reboot issue

This issue can be resolved by running the Sysinternals command line utility ‘PSSuspend.exe’ from inside Windows PE on the VM / Physical machine you are attempting to recover.

NOTE: I originally created all of my BMR ISO’s in 64bit, for the following process to work and for ‘PSSuspend.exe’ to successfully run you must use a 32bit BMR ISO. If you only have 64 bit you will need to create a 32bit version using the Windows Automated Installation Kit (WAIK).

Here are the steps:

  1. Pull down a copy of ‘PSSuspend.exe’ from Technet (https://technet.microsoft.com/en-us/sysinternals/bb897540.aspx)
  2. If you are recovering a physical machine, copy the ‘PSSuspend.exe’ image to a USB drive. If you are recovering a VM and your Hypervisor platform/version doesn’t allow USB passthrough you can try attaching a floppy disk drive and copy the ‘PSSuspend.exe’ to there.
  3. Start the command line within WinPE by choosing ‘Utilities’ then ‘Run’:
  4. In the Run dialog box, type CMD and hit Enter or click OK
  5. In the Command Line Window navigate to the drive/directory where you have ‘PSSuspend.exe’
  6. Run command “pssuspend.exe winlogon.exe”

This will prevent automatic WinPE reboot and allow recovery of a full-system that exceeds a duration of 72 hours. If you have any issues executing the command with errors relating to image type confirm you have booted the physical or virtual machine using the 32bit BMR ISO.

NOTE: The BMR window will continue to count down to zero but no reboot will occur.

Summary and Recommendations

This incident proved to be pretty costly on time and stress levels. Sure, the solution worked and the affected applications (Citrix Xenapp and Exchange) were operational within 15 minutes of a serious failure. However, there was noticeable performance degradation due to the DR infrastructure being inferior to that of the primary (Budget constraints) so it was imperative to get the VM’s back on to the primary kit asap. Unfortunately this took way to long. If you are running this solution, or planning to, include the following tasks and testing to your plan during build and production with regular testing:

  1.  Ensure you have 32bit BMR’s for all products (Arcserve Backup, UDP & RHA)
  2. Download and test the ‘PSsuspend.exe’ utility in your environment for physical and virtual workloads
  3. Consider the re-sync time for every protected server both physical and virtual in the poorest possible network conditions with regard to jitter, latency and bandwidth
  4. Manually configure the TCP buffer and TCP stream count on your scenarios based on testing from the smallest to largest servers. Do not leave it to ‘autotune’… she bites…

 

 

 

 

 


by Leave a comment

Intel, Cloud Telemetry and Jevons Paradox

I recently heard on a tech podcast that Intel were contributing to the open source community via their open telemetry framework called ‘Snap’. Snap is designed to collect, process an publish system data through a single API.

Here’s a quick diagram along with the project goals taken form the Github page that will provide you with a simple overview:

Snip20160523_1Project Goals: 

  • Empower systems to expose a consistent set of telemetry data
  • Simplify telemetry ingestion across ubiquitous storage systems
  • Improve the deployment model, packaging and flexibility for collecting telemetry
  • Allow flexible processing of telemetry data on agent (e.g. filtering and decoration)
  • Provide powerful clustered control of telemetry workflows across small or large clusters

The Intel representative went very deep and wide on how Snap works from both operational and development perspectives. All very exciting, especially when a tech company  like Intel uses it’s resources to contribute to open source. Naturally, like many others I do get a little suspicious. Why are they doing this? What’s in it for them? What’s the hidden agenda?

As I was thinking about this, one of the show hosts asked the Intel rep the self confessed cynical question… he stated that it all sounded very useful and technically interesting but why would Intel spend time on this ‘open source’ stuff? What’s in it for them? Intel responded quite honestly about their motives. They said it wasn’t ‘Rocket Science’. They want consumers to buy more silicon… more Intel chips, it’s no secret. They then went on to talk about ‘Jevons Paradox’ which I found very interesting. Intel’s Snap wasn’t an expensive project using a lot of their expertise and engineering resources with no return on investment, it was a project that supports a business model.

Jevons Paradox, sometimes referred to as ‘Jevons Effect’ states that the use of a resource tends to increase rather than diminish the more efficient it becomes. The following diagram clearly shows the concept using the cost of fuel, taken from the Jevons Paradox Wikipedia page:

Snip20160523_4

Using this proven theory, Intel believe that the easier they make the monitoring and the analysis of their chipsets via an open source telemetry framework, the more they will be consumed, meaning customers will buy more Intel chips. The open plugin model means that community and propriety plugins can be loaded into Snap so it can be easily be extended and tailored to meet even the far left field business needs in the analytics space.

The team over at Grafana were quite impressed by Snap, so much so that they created Snap datastore. If you are yet to hear of Grafana an what it does, I briefly discuss it in a previous article found here. In short, it’s an open source dashboard for system monitoring. Having the Snap datastore in Grafana means you can natively create monitoring tasks and metrics without having to jump through a load of hoops.

CPU monitoring in Grafana using the Snap datastore connector: 

cpu-stack-grafana

For more information on the Intel Snap project visit the Github page here:

https://github.com/intelsdi-x/snap

And, to read more on the Jevons Paradox, checkout the  Wikipedia page here:

https://en.wikipedia.org/wiki/Jevons_paradox

Share the chatter! Cheers

 

 

 

 

 


by Leave a comment

Citrix PVS Image Process – Best Practices

On completion of the implementation and handover of any technology to an IT department / client, high quality build and configuration documentation is a must. This may seem obvious but I’ve been in many situations where project time gets squeezed due to budget or to get a deal over the line and a ‘day or two’ gets lobbed off the documentation phase. This leads to inadequate and poor quality documentation which may not be an issue at first, but down the line when someone else has to take over the environment or troubleshoot it can be nothing short of a nightmare.

If documentation is up to scratch and training workshops are provided, it will empower the client to take over and confidently manage the environment, and in some cases, carry out future upgrades. Some integrators may see this as bad business from a revenue perspective, but I believe customers are likely to consume more services in the future when they are confident you are providing them with the correct traning and tools. And, realistically, internal IT departments are typically way too busy to take on more than what they already have on their plates, but it’s good practice to give them the option.

Now back to point of this blog post; one of our clients had the time and resource to invest in the internal IT team following the positive start in documentation and training provided by us. They asked us to provide some best practice tips around the PVS imaging process in preparation for a PVS upgrade they were taking on internally. We, the Citrix Engineering and Consulting team, came up with the following, it was written over a year ago and has had the input and review of around 6 senior Citrix engineers and consultants. I still refer to it and find it relevant so here it is:

Provisioning Services: Image Creation

Assumes that the image is working with an attached local drive. The attached local drive is typically created/placed on high speed or near high speed storage according to environment needs or constrains.

The following items are configured within the image and surrounding infrastructure to optimise performance, utilisation, compatibility and management;

1. Redirect PageFile from %SystemDrive% to a local drive.

2. Crash dumps;

  • Totally disable crash dump processing,
  • Or, configure as mini dump only and redirect to the local drive.

3. Disable or minimise as much write operations to the “%SystemDrive%” as possible. Ideally, write operations should be restricted to the ““%SystemDrive%\Users” path only.
As a simple example, exclude *ALL* optimisation and scanning tools such as;

  • Disable scheduled defragmentation tasks of the “%SystemDrive%”.
  • DDL optimisations, including Citrix DDL optimisation.
  • Deploy Antivirus exclusions for key operating components and files (refer to current Citrix and vendor recommendations).

4. Windows Event logs redirected from “%SystemRoot%\System32\winevt\Logs” to the local drive. This may be done as either;

  • Policy based redirection on a per log basis,
  • Or (recommended), using junction point redirection on the “Logs” folder to capture all logs.5. Application log redirection – if required. This may be done via vendor recommended configuration or junction point redirection.

6. Keep the design simple. Complex designs introduce complex problems that are often extremely difficult to diagnose or isolate. In general, always try and use vendor default paths, settings and configuration. Only deviate from this where a vendor has a clearly defined best practice procedure to allow this.

  • It is an unfortunate fact of life that programmers often accidentally hard code configuration options into applications and the operating system. Tricky or complex deviations from vendor recommendations often lead to obscure, intermittent or strange behaviours that can be extremely difficult to diagnose.
    If you use only vendor recommended configuration changes, then you have a much higher assurance that the vendor will include full testing in their hotfixes and patching procedures.

7. All applications should be validated to confirm that they do not place ephemeral (temp, batch or data), or user specific files in in any of the following paths; %SystemDrive%, %SystemDrive%\TEMP, %SystemRoot%, %ProgramFiles%, %ProgramFiles(x86)%, %CommonProgramFiles%, %CommonProgramFiles(x86)%, or any other similar path. Note; application global configuration files used by all users are exempt from this rule.

8. All applications should be validated to confirm that they do not create server specific configuration settings. This includes both registry and file based configuration – including INI, XML, CFG, DAT, etc, files.
Note: Special attention should be made to look for server unique settings such as GUID strings like “{BB2E617C-0920-11d1-9A0B-00C04FC2D6C1}”, that may uniquely identify a server for AntiVirus, Firewall, licencing’s, etc, configuration.
If application unique settings are encountered, these unique server settings should be set via the Provisioning Services device TARGET personality strings. Thus, can be configured within the Image during each server’s boot sequence.

9. Do NOT redirect application installation paths. This may include changing %ProgramFiles%, %ProgramFiles(x86)% locations or the installation path of applications.

  • It is an unfortunate fact of life that programmers can accidentally hard code program paths into application operate. This may lead to obscure, intermittent or strange application behaviours if an application is not installed in its default path.
    In addition, be extremely careful with changing application configuration settings outside of those provided in the application’s own configuration files or registry settings.

10. Good practice application tips also include;

  • Try and minimise any situation where application executables are run from network shares. In addition, this also includes opening database files from network shares.
    ▫ It is understood that occasionally the only option is to place some applications on network shares due to limitations on their design or age.
  • Removal of any unnecessary application based Taskbar items or background services.
  • Removal of any unnecessary Start Menu or Desktop icons. This includes shell based namespace items held in the registry.

11. Utilise user “home folder” shares to store application per user settings.

12. User based Folder Redirection policy applied via GPO.

13. Deploy Citrix Profile Manager based profile management. This will ensure that multi-session &/or disconnected sessions do not encounter the synchronisation issues.

14. Consider segmenting PVS streaming traffic to a dedicated VLAN if the network has a highly utilized or potentially saturated. This can also be implemented for security purposes if the business require it. Note, segmenting PVS traffic used to be a Citrix best practice but is no longer the case for the vast majority of deployments.

15. TCP Large Send Offload option allows the AIX TCP layer to build a TCP message up to 64 KB long and send it in one call down the stack through IP and the Ethernet device driver. The adapter then re-segments the message into multiple TCP frames to transmit on the wire. The TCP packets sent on the wire are either 1500-byte frames for a Maximum Transmission Unit (MTU) of 1500 or up to 9000-byte frames for a MTU of 9000 (jumbo frames).

16. Re-segmenting and storing packets to send in large frames causes latency and timeouts to the Provisioning Server. This should be disabled on all Provisioning Servers and clients.

17. Disable Large Send Offload, open the Network Interface Card (NIC) properties and select the Advanced tab.
Some NICs do not offer this setting in the properties page. In this case, you must change a registry key change to disable Large Send Offload. To disable, add the following entry to the registry:

  • Target Device
    Note: For Provisioning Server 6.0 and beyond, BNNS driver is no longer used for Windows 7 and 2008, so this registry key is not applicable. However, BNNS is still used for windows XP and 2003.HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BNNS\Parameters\
    DWORD = EnableOffload
    Value: “0”
  • Provisioning Server and Target Device
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters\
    Key: “DisableTaskOffload” (dword)
    Value: “1”

18. Hard code all PVS ports on the servers & clients to avoid auto negotiation network speed, this can cause slow start up times and PXE timeouts for target devices.

19. Firewall and server to server communication ports.

Open the following ports in both directions:

  • UDP 6892 and 6904 (For Soap to Soap communication – MAPI and IPC)
  • UDP 6905 (For Soap to Stream Process Manager communication)
  • UDP 6894 (For Soap to Stream Service communication)
  • UDP 6898 (For Soap to Mgmt Daemon communication)
  • UDP 6895 (For Inventory to Inventory communication)
  • UDP 6903 (For Notifier to Notifier Communication)

Provisioning Services: Image Closure

The provisioned image should typically assume a local drive is attached for the storage of; WriteCache, PageFile redirection, Windows Mini dumps (only if absolutely required), Windows Event Logs, and Application specific logs.

Any other server specific personality settings should be set via the Provisioning Services device TARGET personality strings.
Confirm the following:

1. Refer to the “Image Creation” sequence and validate all items. Specific focus should be on any additional applications that have been added or modified in the environment. Then focus on the best practice steps associated with applications. E.g.

  • Personality strings set, as required, for applications that require personality traits.
  • Confirmation of shared folder usage. Specifically; applications should not place ephemeral (temp, batch or data), or user specific files in %ProgramFiles%, %ProgramFiles(x86)%, %CommonProgramFiles%, %CommonProgramFiles(x86)%, %SystemDrive%, or %WinDir% paths.

2. Using a Domain account with local Admin rights, login and reboot the server. If you wish, you may also perform a final “GPUPDATE /FORCE”.

3. Login as the local machine Administrator account and remove:

  • Any roaming or local user profiles on the server image created or left from the creation or update of the server image. This must be validated in three (3) locations;
    ▫ Remove the extraneous profiles using the Windows Profiles dialog under the “Advance System Settings”.
    ▫ Verify there are no extraneous profile folders in “%SystemDrive%\Users”.
    ▫ Using regedit, verify there are no extraneous profiles in “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList”. Specific attention should be focused on any “.bak” files.
  • Any / all temp files created on the %SystemDrive% &/or sub folders.

4. Using the Citrix Role Manager, perform a XenApp prep for image closure. Do not remove the server from the Farm. Then shutdown gracefully in preparation for image closure in PVS.

5. When using Citrix UPM 4.x in the image, remove the UPM cache file (not applicable to UPM 5.x)

6. Run ‘ngen /ExecuteQueuedItems’ for all CLRs (2.0 x86, 2.0 x64, 4.0 x86, 4.0 x64) in order to precompile assemblies, if this step is not performed, ngen will run the pre-compilation at random times after every reboot in PVS standard mode and therefore cause significant IO load.

Thanks for reading, share if you found this useful.