“TerminatingError: Error retrieving item from path” while using PowerShell code when creating Machine Catalogs for MCS in Azure

PowerShell cmd let “$provScheme” fails with following error while creating MCS catalog on Azure using Citrix blog with Narrow Scope Service Principal:

PS C:> $provScheme

TaskId : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Active : False

Host : Server name

DateStarted : mm/dd/yyyy hr:mm:ss AM/PM

Metadata : {}

Type : NewProvisioningScheme

Status : Finished

CurrentOperation :

TaskExpectedCompletion :

LastUpdateTime : mm/dd/yyyy hr:mm:ss AM/PM

ActiveElapsedTime : 1

DateFinished : mm/dd/yyyy hr:mm:ss AM/PM

TerminatingError : Error retrieving item from path /IMAGE-resource-group.resourcegroup/imagestorage.storageaccount/images/IMAGE-name.vhd.vhd Not appended with a valid AzureInvetoryType.

Parameter name: fullPath

Actual value was IMAGE-resource-group.resourcegroupimagestorage.storageaccountimages.container.

Storage : {}

WorkflowStatus : Terminated

You may see following exception in Powershell:

“Invalid provisioning scheme”

Citrix Studio would show following error:

User-added image

User-added image

Application event log in Delivery Controller has following event logged:

Log Name: Application

Source: Citrix Machine Creation Service

Date: mm/dd/yyyy hr:mm:ss AM/PM

Event ID: 2007

Task Category: None

Level: Error



Computer: <FQDN ServerName>


Provisioning scheme creation workflow operation failed : System.InvalidOperationException: UnknownError in Create ProvScheme, Get snapshot {0} —> PluginUtilities.Exceptions.WrappedPluginException: Error retrieving item from path /IMAGE-resource-group.resourcegroup/imagestorage.storageaccount/images/image-name.vhd.vhd —> PluginUtilities.Exceptions.WrappedPluginException: Not appended with a valid AzureInvetoryType.

Parameter name: fullPath

Actual value was image-resource-group.resourcegroupimagestorage.storageaccountimages.container.


  • No Related Posts

Unified Endpoint Management with the Latest Release of ZENworks 2017

Gil Cattelain

As an organization grows, the often-fragmented endpoint management that worked in a smaller company starts to present a significant risk. Scaling requires a user-centric approach with a focus on security and self-service access to your organization’s most necessary applications. Cloud-based apps that offer universal access from any device are flexible, but legacy support is equally …

+read more

The post Unified Endpoint Management with the Latest Release of ZENworks 2017 appeared first on Cool Solutions. Gil Cattelain


  • No Related Posts

“Unable to connect to the server. Contact your system administrator with the following error” When Launching Desktop

Adaptive transport is a new data transport mechanism for XenApp and XenDesktop and available in Citrix policies.

When set to Preferred, data transport over EDT is used as primary and fallback to TCP. By default, adaptive transport is disabled (Off) and TCP is always used. For testing purposes, you can set Diagnostic mode, in which case only EDT is used, and fallback to TCP is disabled.

First Test with policy set to Preferred. [No UDP Ports are opened]

  1. Launch the Desktop.
  2. From command prompt browse to “C:Program Files (x86)CitrixSystem32”
  3. Run ‘CtxSession’

You can see that TCP is being used with CGP (Session Reliability) and Session Reliability encapsulates the ICA protocol.

User-added image

Run CtxSession /v for a verbose output. Here you can see the port 2598 being used on the VDA.

User-added image

Now set the policy to ‘Diagnostic mode’.

Ensure UDP 1494 and 2598 ports open on the VDA I connect back to the Citrix desktop, run CtxSession /v and receive confirmation that we are now using UDP 2598. This means that HDX Enlightened Data Transport is being used with Session Reliability. You can also check Director and note the protocol will be set as UDP.

User-added image


  • No Related Posts

SEP 14.2 Unmanaged – Trial License expiration?

I need a solution

Currenlty, I am running SEP 14.2 Unmanaged and would like to know if what will happen to some components if my Trial expires?

I heard that Download Insight or Cloud File Reputation Lookup will be disabled.

But what about Auto-protect? Will Auto-Protect be disabled as well?

Will I still get LiveUpdates as well?

I only need the basic components, especially Auto-Protect. The Cloud File Reputation Lookups not really needed since I do not download a lot of  files or programs on my system.

Have attached a print screen on what might get disabled when the Unmanaged version Trial expires.



  • No Related Posts

How to Uninstall from Cloud Portal

I need a solution

Is there a way to mass uninstall “Symantec Endpoint Protection Cloud” from the cloud portal? 

I’ve been searching for a way to automate removal of all the installed client in my network which have at least 400 computers. 

It’s a mix of domain and workgroup computers so I cannot push it through GPO.

Any suggestion would be appreciated.



  • No Related Posts

Dell Technologies Cloud Service Provider Summit 2019

CSP Summit graphic.jpg

We’re excited to start the year with the Dell Technologies Cloud Service Providers Summit, which will be held from 22nd to 24th January 2019, in Lisbon.

Exploration is at the core of innovators and new business models. Magellan, Vasco de Gama, and Cabral will be our navigators for this Summit. This year, selected CSP partners are participating in a cloud conference focusing on ideation and out of the box thinking through new technologies, design thinking and brainstorming as well as feedback sharing. This environment, full of creativity, is made to develop new services, improve existing relationships and create new ones, to support your business strategies, your revenue growth and your operational sustainability.

Those 2 days will be an opportunity to network, gather insights on our strategy, design your future services, and forge new partnerships with Dell Technologies, Intel and your peers. Together, we will also have an unmissable opportunity to interact with Dell Tech leadership and design our future – Together.

Find out more about our Cloud Service Provider programme here: https://dellemc.com/cloud-service-providers.

Follow #DellTechCSP on Twitter during the event, if you can’t attend.

Ahead of our Dell Tech Cloud Service Provider Summit, where will explore the future of cloud, we are asking YOU:

Tweet us an example of cloud innovation that inspires you? Use #DellTechCSP in your answer.

Cloud Service Providers Summit - innovation.png


  • No Related Posts

The Value of Azure Stack as an IaaS Platform


Out in the field with customers and partners, we hear an awful lot about what people think Azure Stack is and isn’t, what its capabilities are, and where it should or shouldn’t be used when needs arise for an on-premises solution.

“There’s no point in just moving existing VMs into Azure Stack, there are already established virtualization platforms with rich ecosystems which will run them just the same and for a lower cost'”

“Sure Azure Stack can run VMs, but it’s really designed as a PaaS first platform, not for IaaS.”

“Azure Stack is a platform for modern applications, there’s no point in just using it for VM workloads.”

“I already have an IaaS platform that I’m depreciating over the next four years, I don’t need another more expensive one to do the same thing.”

Each of the above is a commonly held belief about Azure Stack, and each of them is definitely built around a grain of truth, while at the same time missing or not embracing much of the larger picture around Azure Stack, and indeed Azure and other public cloud platforms.

To be fair this isn’t anyone’s fault in particular; Azure Stack is a nascent product, and as such messaging around it has pivoted multiple times since it was first announced over three years ago. It wouldn’t have been seemly to have been seen to be competing with Hyper-V in any way, and so it was announced and positioned as a PaaS-first play, bringing the rich goodness of Azure platform services back to the edge! While that’s still true, at the same time it really does do Azure Stack a massive disservice.

So firstly, let’s be clear – Azure Stack doesn’t replace Hyper-V, or VMware for that matter.

Secondly, Azure Stack is a brilliant IaaS platform for running VM workloads.

Ok, in retrospect, that wasn’t so clear – let’s break it down.

Virtualization, Advanced Virtualization, and IaaS are three distinct capabilities which are often conflated.

2.pngInfrastructure as a Service isn’t simply the ability to run virtual machines, it’s a set of management constructs on top of a hypervisor on top of a fully automated infrastructure which support and deliver the essential characteristics of a Cloud computing platform.

This isn’t a new message from Dell EMC, in fact it’s been consistent for quite some time now. Rather than rehash previously trodden ground, I’ll instead just recap with a link to Greg’s excellent blog below.


A lot has changed in Azure Stack in the last year and a half though, and that in and of itself isn’t surprising, nor should it be. Azure Stack updates are released on a regular basis, bringing with them new capabilities and improvements, including of course in the IaaS space.

Over and above the monthly updates, and far more importantly though, customers have now had their hands on Azure Stack for over a year since official GA launch, and we have a much better idea of the interesting, innovative, and sometimes downright cool scenarios they’re using Azure Stack for in the real world.

Of course the available Azure PaaS Services are used with gusto, that goes without saying – people prefer to use native PaaS features wherever they can! The Azure App Service and Azure Functions are my personal favourites. Below is a quick Twitter poll I ran, just to gauge if indeed this was general sentiment, and while decidedly unscientific, the results were interesting.


But while Azure Stack is indeed a great PaaS platform, it is definitely not a PaaS only platform, and nor for that matter is Azure by any stretch of the imagination.

Indeed one of the fastest growing parts of Public Azure today is through the migration of existing (appropriate) workloads into Azure as VMs, and don’t worry we’ll cover off what appropriate means a bit later on. This doesn’t involve any day one workload transformation or changes to how applications are running, it does typically bring some immediate benefits though, and those benefits are largely the same, or dare I say… consistent, in Azure Stack.

Benefit #1

Firstly, and probably most importantly, you don’t need to design, deploy, or manage any of the underlying hypervisor or software defined constructs. All of the extremely complex virtual infrastructure which goes into running a platform like Azure Stack is delivered as an appliance, consistent every time.


In most businesses, large portions (if not the majority) of an ops team’s time and energy goes into the ongoing management of the infrastructure which supports their workloads. Azure Stack is designed to give pretty much all of that time back. In Azure Stack, all of the hypervisor components, the host OS, the software defined networking, the software defined storage, and everything that goes around and supports them is delivered as a turnkey solution, and then patched and updated automatedly as part of regular Azure Stack updates, albeit scheduled by you, the admin.

Each of the dozens of Virtual Machines running on top of the platform to support and deliver Azure Stack itself are locked down and delivered to you as a service. Azure Stack updates are delivered on a mostly-monthly cadence, and while they take some time to run, they are fully automated end to end. This includes not just the hypervisor and software defined constructs, but also the ongoing patch and update all of the virtual infrastructure required to deliver Azure Stack itself.

Through Dell EMC, OEM updates are also automated through our Azure Stack patch and update tool, a unique capability in the Azure Stack OEM market. One of the greatest benefits a true cloud platform delivers is automating you away from the hum drum to where you can spend your time most valuably. Where any part of that solution from bare metal to cloud isn’t automated, not only is there potential for human error and configuration drift, your valuable time is also being wasted. Today, uniquely, Dell EMC provides you both that consistency and that time back.

Benefit #2

The second benefit to Azure Stack comes through its consistency with Public Azure. Any time and skills investment into learning Public Azure automatically translates to Azure Stack, and vice versa. Any infrastructure as code templates developed through the likes of ARM or Terraform can, with some caveats, work across each platform. Potentially most importantly though, Azure is a mature platform which has been around for many years now, and as such has a robust and well established community.


Many of the challenges you’ll encounter, solutions you’ll want to deploy, or knowledge you want to gain have already been round the houses in Public Azure. There are many, many public repositories of infrastructure templates out there in the community just waiting to be deployed, and many knowledgebases and courses ready to be scoured for knowledge.

Take the Azure Stack Quickstart Template Gallery for example. There are dozens of pre-built templates there covering a plethora of IaaS application use cases, everything from a single Windows or Linux VM to an Ethereum consortium blockchain infrastructure, and a huge amount in between. Each of these templates can be used as a starting point, or in some cases a finishing point, for deploying your own IaaS infrastructure in Azure Stack.

When you enter into the Azure Stack community, you also enter the wider Azure community, and having a community that well established and open is of incredibly value.

Benefit #3

The Azure Marketplace is an IaaS-centric ‘app store’ for the cloud, where software vendors certify through Microsoft and then make available golden images of their software to anyone who wants to deploy it into Azure. Sometimes the resultant VMs are managed by you, sometimes they’re delivered as more of an appliance-based offering. Sometimes they’re a single VM, sometimes a whole infrastructure will be deployed to deliver the service requested.


The marketplace is one of the most well used parts of Azure, and again note that its focus is not in other Azure PaaS services. It’s in delivering as much value from IaaS as possible, giving you images you know you can trust, which have been battle-tested at hyperscale, and which are typically kept up to date by the very people who create the software running on them.

This same marketplace experience exists in Azure Stack, and through it you have the ability to choose which marketplace images you want to syndicate to your own Azure Stack. Every image isn’t downloaded by default, as they take up some space, so you choose what ones make sense to you, and then make use of them knowing that they’re the exact same images as you would deploy in Public Azure.

Benefit #4… to #n

There are many more benefits to ‘just’ running virtual machines in Azure Stack, from the automated patching of SQL workloads, to the continued three year support of Windows and SQL Server 2008/R2 workloads, to being able to access cloud constructs like object, table, and queue storage, to leveraging VM Scale Sets for horizontal scalability of traditional workloads, to pre-validation for compliance standards like PCI DSS, to service measurement for chargeback, to built-in load balancers, to built-in site to site VPN capabilities, to managed disks and the removal of VM disk and storage management, to extensions providing features to VMs like anti-virus and VM patch and update, to integration of those IaaS workloads with higher tier PaaS capabilities… and so it goes on. The benefits are myriad, and in retrospect should be unsurprising given the popularity of Public Azure for IaaS workloads.

An Azure Stack Operator does still have administrative tasks to carry out it’s true, but they are not the same as a virtualization admin, or even an advanced virtualization admin. As we’ve said, all of the underlying infrastructure that delivers the Azure services is delivered ‘as a service’, so as ever in cloud your attention is pushed higher, focusing on more rapid update cadence, capacity management, offering services, chargeback, and other more cloud-centric operating tasks.

Azure Stack doesn’t replace Virtualization

There are two core routes to IaaS workloads entering an Azure Stack:

Fresh Deployment

If you’re deploying a fresh infrastructure, you may be doing it to create a new application, or to deploy your own in-house application, or to install a third party vendor’s application. For the first two of these, Azure Stack can provide a great platform assuming you follow cloud application development patterns for resiliency. For the third, you’re largely in the hands of the vendor. If they require specific hypervisor features, or shared storage between VMs, or specific CPU:RAM:Storage ratios, or high performance OS disks, or… well, all the same reasons an application can’t be deployed into Azure apply to Azure Stack.

There’s an enormous mass of software out there which will never be rewritten for a cloud-native environment, and yet more which is suited best to environments with more customizability than Azure or Azure Stack provides. For those workloads, existing virtualization platforms with their rich and well established ecosystems remain the best place to run them, even if deploying fresh.


If you are deploying a fresh infrastructure over which you have application control, there’s a whole host of cloud-native tooling available to transform how you design, manage, and maintain that application. Infrastructure as Code, VM Scale Sets, Service Fabric and Kubernetes templates, and more all exist to allow you to apply the same DevOps principals to your VMs in Azure Stack as you can in Azure.


Migrating VMs to Azure Stack is largely the same in principle as migrating VMs to Azure, and just like in Azure, serious consideration needs to be given to the workload and how (and indeed if) it will run well within the cloud environment. Typically some resizing will need to be done to fit an Azure Stack VM ‘t-shirt’ size, and testing will need to happen to ensure the workload performs as required in the bounds of Azure Stack IOPs limits. For these reasons and more, when evaluating Azure Stack as a platform it’s critical that you evaluate it against the workloads you’ll be running, not just the aggregate CPU/RAM/Storage you think you’ll need. .

Probably the most important consideration for any deployment or migration into Azure or Azure Stack is that these are platforms designed for cloud workloads. The most fundamental difference between a cloud workload and a traditional workload is that workload availability should be delivered and accounted for by the application, not by the infrastructure. That’s not to say that Azure Stack isn’t a highly available and resilient platform within a rack, it is, however if a workload needs to be but cannot be resilient (and in particular resilient across site or rack if needed) without traditional hypervisor or storage technologies, then it may not be best suited to run in a cloud platform.

Never Forget: Azure Stack is Azure

Azure Stack is undoubtedly an incredibly powerful IaaS platform, boasting features like the Azure Marketplace that don’t even exist in other on-premises platforms. If your workload can be deployed or migrated into Azure Stack, and it does perform well, then all of the above benefits will apply to it. You’ll find yourself with an up to date, patched and secure environment, which gives you the time back to start working on higher tier PaaS services without being additive to existing tasks.

Ultimately though the core of the matter is that when you deploy or migrate virtual machines into an Azure Stack environment, you’re not just making use of a hypervisor, you’re gaining the power, the ecosystem, and the community of the Azure Cloud, and that’s a glorious place to be.


  • No Related Posts

PCF is Known for the Best App Deployment Experience. Now It’s Even Better with Zero Downtime Updates for Pretty Much Everything.

EMC logo

When you want to get your code from laptop to production, there’s nothing better than Pivotal Cloud Foundry. Just cf push your app, and the platform does the rest for you. Moments later, your updates are in prod.

Platform operators have their own glorious workflow. With Pivotal Cloud Foundry (PCF), patches, updates, and upgrades are automated and effortless.

Both sets of capabilities are on full display in PCF 2.4, which is now generally available. Let’s start by looking at how the app deployment process gets better.

PCF now supports native zero-downtime rolling deployments. Cloud Foundry has supported blue-green deployments for a while. But you needed two app versions, and some client-side orchestration to make it work. Now, client-side coordination is no longer required. Instead, the coordination now happens on the other side of the PCF API. It’s not a substitute for a full-featured CD tool, but it’s handy in lots of scenarios. Try it out as a beta in PCF 2.4!

Developers can scale their app in new ways in PCF 2.4. App Automator (in beta) allows you to define scaling rules based on custom app metrics. This new service uses other new capabilities (like the Metric Registrar and the new Log-Cache metrics endpoint) to give you more control over how your app behaves. 

Here’s what’s new for platform teams in PCF 2.4:

  • Dynamic egress policies. Want to make a policy change with Application Security Groups (ASGs)? In the past, you had to restart your app. Now, operators can instead use dynamic egress policies to make policy changes with zero downtime. This feature debuts as a beta, as well; experiment with them to see how they can replace ASGs over time. Say goodbye to those annoying app restarts!

  • Zero-downtime stack updates. In PCF 2.4, the new cflinuxfs3 rootfs (based on Ubuntu 18.04 LTS) is the default stack for new apps. With previous versions, migrating your app to the new stack would have required a restage and restart. Now the platform executes this in a automated and rolling fashion. That means no effort and no downtime.

  • PCF 2.4 continues the zero-downtime OS updates across the whole platform. Dealing with Operating System end of general support dates can be stressful, but with PCF this should be a minor and fully automated change in your environment.  More PCF software has updated to Ubuntu 16.04 with this release ensuring you can keep getting non-disruptive security updates for all software on the platform.

Zero downtime stack updates are a massive boost to productivity. Engineers can just go about their day, while PCF updates the bits under the hood.

But you really start to appreciate the power of zero-downtime updates when a new CVE hits. And what do you know, a Kubernetes Critical CVE was revealed earlier this month. Pivotal tested the fix, and pushed it out shortly after the vulnerability was discovered. Many Pivotal Container Service customers had their Kubernetes clusters patched in production before the news about the CVE became public. We recap this story below because it’s a terrific example of how you should run your most important business systems.

In PCF 2.4, your InfoSec teams will want to know about the additional TLS encryption and a new scanning tool to assist with compliance.

The other great thing about the automation PCF brings to your enterprise is that comprehensive security is baked into the platform. Developers inherit loads of security controls from PCF. For example, CredHub protects your passwords and other secrets, you get multi-tenancy through the permissions model, and you enjoy automated dependency management with buildpacks. (And your platform teams keep PCF in a healthy state using the aforementioned automated process.)

On to the release highlights!

Native Zero Downtime Rolling Deployments: A Powerful Addition to the Blue-Green Approach (beta)

Dynamic Egress Policies Overcome the Limitations of ASGs (beta)

Zero Downtime Stack Updates to cflinuxfs3: We Maintain the Base rootfs in Your Containers So You Don’t Have to

Zero Downtime OS Updates: Just Say No to Managing Operating Systems

PKS Fixes the Kubernetes Critical CVE with Zero Downtime

Compliance Scanner for PCF (beta)

Configure Scheduling and Scaling Events with App Automator (beta)

Apps Manager Adds Global Search, Greater Parity with the cf CLI

Emit Custom App Metrics to PCF with Metric Registrar

Operations Manager – Zip Through Your Day with These New Capabilities

MySQL for PCF 2.5: Now with HA via Galera Clusters

Use TLS to Encrypt Connections to Internal, External MySQL Instances

Connect Your Apps to File Servers with SMB Volume Services

Other Announcements

Native Zero Downtime Rolling Deployments: A Powerful Addition to the Blue-Green Approach

One popular way to reduce risk when rolling out a new version of your app is to use a blue-green deployment. Here’s the scenario:

Blue-green deployment is a technique that reduces downtime and risk by running two identical production environments called Blue and Green.

At any time, only one of the environments is live, with the live environment serving all production traffic. For this example, Blue is currently live and Green is idle.

As you prepare a new version of your software, deployment and the final stage of testing takes place in the environment that is not live: in this example, Green. Once you have deployed and fully tested the software in Green, you switch the router so all incoming requests now go to Green instead of Blue. Green is now live, and Blue is idle.

Cloud Foundry has supported this scenario for quite some time, but you had to have two different versions of an app plus some homegrown scripting or orchestration. Now, PCF 2.4 gives you the option to do a similar process natively in the platform. First, cf push an app (i.e. your-app-name) like normal. Then, when you want the platform to cut-over to the new version, you just type:

cf v3-zdt-push your-app-name

From there, PCF gradually brings instances of the new version online. As they prove to be working and healthy, the older versions are subsequently removed. This option isn’t meant to be used in lieu of a continuous deployment tool. But you’ll find it useful for loads of other scenarios, like performance tuning, code-level security fixes — even chaos engineering!

For a screenshot tutorial, check out Richard Seroter’s thread:

You can also watch Zach Robinson’s demo from Cloud Foundry Summit earlier this year.

Dynamic Egress Policies Overcome the Limitations of ASGs

Long-time Cloud Foundry operators are intimately familiar with Application Security Groups (ASGs). Operators use ASGs to control how applications interact with off-platform services. With ASGs, you create and manage rules that specify the protocols, ports, and IP address ranges where application or task instances send traffic.

ASGs work fine for the most part. But there is one annoying thing about ASGs: you have to restart your apps when you apply a new policy or update an existing one. This results in undesirable downtime. Another constraint with ASGs is that permissions are too coarse. Policies can only apply at the space level, not the application level. So you must grant access to an external service for all the apps in a given space, even if you just need a single app to talk to said service.

In PCF 2.4, there is a better way to govern these traffic flows: Dynamic Egress Policies, a beta capability in PCF 2.4. (This feature was released as part of open source Cloud Foundry v2.19.0.) With Dynamic Egress Policies, you can configure egress policies for CF apps and spaces, just by using the IP address range.

Want to drill into this feature more? Check out this superb technical blog post from Preethi Varambally. You can also review the docs in the cf-networking repo.

Zero Downtime Stack Updates to cflinuxfs3: We Maintain the Base rootfs in Your Containers So You Don’t Have to!

In PCF 2.3, Pivotal added support for the Ubuntu 18.04 stack and cflinuxfs3 for all supported buildpacks. New installs of PCF 2.4 will run the cflinuxfs3 stack and related buildpacks by default.

A few items to note:

  • cflinuxfs2 remains the default stack for PCF 2.2 and PCF 2.3.

  • The default stack can be toggled between cflinuxfs2 and cflinuxfs3. This setting will be inherited upon upgrade.

While the upgrade to cflinuxfs3 is seamless, there may be some impact to your apps. Make sure to test them before cutting over to the new version in production. As always, work with your account team to work through this transition!

Zero Downtime OS Updates: Just Say No to Managing Operating Systems

In PCF 2.3, we bumped the OS version of several tiles to Ubuntu 16.04, the latest release. Since then, a slew of additional services have bumped their stemcells to Ubuntu 16.04, including:

It’s almost 2019. Are you still patching your operating systems manually? Or worse, not patching them at all? Ask any Pivotal customer how liberating it feels to never worry about an OS patch again!

PKS Fixes the Kubernetes Critical CVE with Zero Downtime

I like to say there are three certainties in life: death, taxes, and security updates. The Kubernetes world was jolted with a CVE earlier this month when a privilege escalation vulnerability was discovered. Here’s how ZDNet described the issue:

With a specially crafted network request, any user can establish a connection through the Kubernetes application programming interface (API) server to a backend server. Once established, an attacker can send arbitrary requests over the network connection directly to that backend. Adding insult to injury, these requests are authenticated with the Kubernetes API server’s Transport Layer Security (TLS) credentials.

Yikes. Surprised by this? You shouldn’t be. CVEs exist in every piece of software. Expect more of them to hit. The question is how fast can you respond to them. If it’s more than a day, you need to get serious about modernizing your infrastructure operations.

Here’s the good news: we can help you with that! Our own John Allwright explained how PKS customers instantly and effortlessly applied this patch to their Kubernetes clusters before the news was even widely reported:

For PKS customers with automated upgrade pipelines, updates from PivNet are automatically applied to their PKS instances. In this case, these pipelines detected a new PKS release (v1.2.3), and immediately updated the customer’s PKS environments, with zero downtime.

Without an automated process, CVEs are stressful, white-knuckle moments in enterprise IT. This fun video captures how much easier life can be with automated patching for your most important business systems!

Compliance Scanner for PCF (beta)

More and more organizations are leaving the drudgery of OS management to automated platforms. DISA recently updated its Security Technical Implementation Guides (STIGs) to certify the use of embedded operating systems for DoD work.

We are all for this movement, and want to help accelerate it. So we’re launching the Compliance Scanner for PCF. Here’s how this tool will help auditors and compliance teams at big organizations.

There’s a universe of third-party configuration scanners for determining security and compliance in operating systems. By and large, these tools were for the pre-platform era, when the OS wasn’t embedded. So, the industry needs scanning tools that are purpose-built for platforms. Hence, Compliance Scanner for PCF!

The tile includes the best of both worlds: remastered tests that simultaneously fit the stemcell model, while aligning with industry-recognized guidelines for secure configurations. What’s not to like?

With just a few clicks, your compliance team will get a full report on the compliance posture of the entire platform. That means you get the green light to go to production, without waiting for a prolonged compliance period.

The results from the Compliance Scanner for PCF, coming soon!

The Compliance Scanner for PCF includes:

  • The OpenSCAP scanner that does the actual scanning.

  • Tests written by Pivotal Compliance Innovation in YML.

  • XGen: XCCDF Generator, which translates the YML tests to XCCDF formatted XML, as defined by the SCAP standard.

The scanner is now available on PivNet. Grab the bits, then go read the docs!

This piece of tech should make the auditor’s job much easier. Want to make their job even easier? Make sure you send them this whitepaper: Pivotal Cloud Foundry: The Auditor’s Guide!

Configure Scheduling and Scaling Events with App Automator (beta)

Here’s a neat feature. What if you could schedule scaling events for your apps – or schedule recurring batch jobs with a simple manifest file? That’s App Automator, and it’s a beta in PCF 2.4. So how does it work?

Developers can express when & what workloads should run via “Triggers” & “Actions”. These parameters live an App Automater manifest that lives within the app code. The manifest would look something like this:

   type: schedule
cron : @every 10m
   action: run_etl

   type: cf-task
   app: data-cruncher
   command: "./run_etl.sh"
    memory_in_mb: 2048 

App Automator includes predefined Triggers and Actions based on common scenarios:

  • Triggers: schedule/cron, event, and metric

  • Actions: scale, curl, task

 Sure, you can manage scaling with PCF App Autoscaler. And you use Spring Cloud Data Flow for PCF or PCF Scheduler to automate tasks. App Automator’s approach offers two advantages.

  • It’s easier to build pipelines. Scheduling and scaling behavior lives in the App Automator manifest.

  • Simplified operations. No database, no service broker. Just install via CLI, and App Automator is available in the Space.

App Automator will be available in the coming weeks. We’ll update this post with a download link to the CLI plug-in. In the meantime, contact your account team for access!

 Note that App Automator is compatible with PAS 2.2 and above.

Apps Manager Adds Global Search, Greater Parity with the cf CLI

Once you have hundreds – or thousands – of apps running PCF, you’re going to need an easy way to find a specific app or service instance. You may want an easy way to search across your orgs and spaces too.

Now you can, with the new global search capability in Apps Manager! Simply type your search terms in the top search bar, shown below. Hit enter, and the search will quickly return results for that string across all your orgs, spaces, service instances, and apps. 

Apps Manager in PCF 2.4 now features a global search.

 There’s more. Apps Manager is really useful for developers just ramping up on Pivotal Cloud Foundry, especially when compared to the cf CLI. We want Apps Manager to have pragmatic parity with the CLI wherever possible. So, in PCF 2.4, Apps Manager gains additional parity with the CLI for restaging your app and service instance sharing.

Operations Manager: Zip Through Your Day with These New Capabilities

Pivotal wants to help operators efficiently manage the platform and onboard new developments teams. We already talked about all the zero downtime goodness in this release, so let’s dig into new enhancements that unlock efficiency in other areas.

Improved permissions logic eases day-to-day administration.

Ops Manager users with write access can use the UI and API when another user with write access is logged in at the same time. This is the finishing touch on a recent round of new role-based access control features.

Expiring cert warning

PCF now protects several communication pathways with the TLS protocol. TLS, of course, uses certificates to ensure that the “client” and “server” on each side of the transaction are authorized and authenticated to share data. Managing all these new certs gets a little easier over the last 18 months, going way back to PCF 1.12 with certificate rotation APIs. We’ve further enhanced this workflow in PCF 2.4. Now, Operations Manager will now proactively prompt you with a banner when your certs may be expiring soon. Here’s a sample of the UX: 

Operations Manager 2.4 warns you about expiring certificates.

 Now, it’s easier to ensure that your certs stay current!

Bring your own antivirus software for the BOSH Director VM

Need to run antivirus software on the VMs that power PCF? Use PCF’s ClamAV Add-On. Prefer a different option? Now you can bring your own! This option will appeal to operators with specific antivirus requirements.

New tools for IaaS customization – Global CPI extensions

PCF is, of course, a multi-cloud platform. The platform’s underlying cloud provider interface (CPI) handles the subtle differences between IaaS providers for you. The end result is a uniform, consistent operational experience across any private and public cloud. But what if you want to customize how you consume the underlying infrastructure? Now you can customize this experience via self-service, with the new Global CPI extensions feature in Ops Manager. Now hundreds of different config extensions are at your disposal!

Note that Global CPI extensions are API only. In this way, they are quite similar conceptually to the vm-extensions feature announced earlier this year.

“Advanced Mode” offers streamlined workflows for power users

OpsManager “locks” certain fields after a successful deployment. If you need to “unlock” some of these fields, you may do so with via Advanced Mode. As the name suggests, this feature is recommended for advanced users only. And please use this feature in conjunction with Pivotal Support!

Emit Custom App Metrics to PCF with Metric Registrar

Metric Registrar allows app developers to export custom app metrics as native CF Metrics. Developers can use it easily create custom metrics that better signal app health and performance, using standard client libraries like Micrometer or Prometheus.

There is a new CLI plugin which you can install via:

cf install-plugin -r CF-Community "metric-registrar"

This will allow you to register your app with the Metric Registrar and gives you two options for emitting custom app metrics: via a public metrics endpoint or through structured logs.

An Overview of Metric Registrar

One other quick note: this capability is off by default. To enable it, simply go to Ops Manager > PAS > Metric Registrar for the settings.

MySQL for PCF 2.5: Now with HA via Galera Clusters

When you think of a cloud-native database, what attributes leap to mind? On-demand provisioning for sure. You want lots of availability provisions, like leader-follower and automated failover. And you want security built-in, with something like TLS.

Our MySQL tile team has been busy shipping these features (and more!) over the last year. Now in MySQL for PCF 2.5, we’ve added another essential feature your enterprise will appreciate: high availability through Galera clustering.

Now, enterprise application developers and operators can now enjoy resilience and application availability even in the face of platform and network failures. Jagdish Mirani offers this excellent write-up with all the details.

Use TLS to Encrypt Connections to Internal, External MySQL Instances

The adoption of TLS in PCF continues apace in this release. Here’s what’s new on the TLS front:

  • You can configure PAS 2.4 to use TLS for all components’ connections to the internal PXC MySQL database.

  • Similarly, you can configure PAS to use TLS for all components’ connections to an external MySQL database. Just provide a CA cert!

Two other updates, related to TLS:

  • App developers can use CF SSH when a platform operator enables authenticated container ingress. Previously, SSH was disabled in this scenario. That restriction is now gone!

  • Every PCF 2.4 deployment will now feature improved routing consistency, security, and stability from Gorouters to Linux cells. This feature was opt-in in PCF 2.3; now it’s enabled by default.

Need a reminder why PCF loves TLS? Check out this excellent article by our own Brian McClain.

Connect Your Apps to File Servers with SMB Volume Services

Do you use file servers supporting the CIFS/SMB protocol? Then the SMB volume service is for you! It ships as part of the PAS 2.4 tile.

Developers can use SMB volume services to bind existing SMB shares to their apps. The feature supports the key advantage of the SMB protocol: native password authentication, which means you can control access to file shares without the overhead of configuring an LDAP server.

Other Announcements

Concourse for PCF

This service got a significant security upgrade: user-based authentication. Previously, you had to log in under a specific team without an association to a user. In Concourse 4.2.1+, users can authenticate into teams as specific users. (Users can be added to a team by configuring the team’s whitelist as described in Configuring Team Authentication.) Another cool thing about this feature: it enables the possibility of other security capabilities, like role-based access control. Stay tuned on this front!

PAS for Windows 2.4

Two things of note on the Windows and .NET side of the house:

  • Operators can now control the density of Windows cells. This is a useful feature if you want to trim your infrastructure costs.

  • Pivotal now provides and maintains a Windows Stemcells for AWS GovCloud. You can now use PAS for Windows to run .NET workloads on this IaaS target.

Built-in MySQL database

If you are using the PAS built-in MySQL compatible database (rather than an externally managed MySQL), you must complete the transition from MariaDB to Percona in PAS 2.3 or prior before the PAS 2.4 upgrade. Read more about the straight-forward migration procedure here.

Try Pivotal Cloud Foundry for Free

Ready to get started? You can take PCF for a spin on Pivotal Web Services for free. Want to dive into the release a bit more? Check out the links below and read up on the newest capabilities. Then make the move to Pivotal Cloud Foundry!


This blog contains statements relating to Pivotal’s expectations, projections, beliefs and prospects which are “forward-looking statements” within the meaning of the federal securities laws and by their nature are uncertain. Words such as “believe,” “may,” “will,” “estimate,” “continue,” “anticipate,” “intend,” “expect,” “plans,” and similar expressions are intended to identify forward-looking statements. Such forward-looking statements are not guarantees of future performance, and you are cautioned not to place undue reliance on these forward-looking statements. Actual results could differ materially from those projected in the forward-looking statements as a result of many factors, including but not limited to: (i) our limited operating history as an independent company, which makes it difficult to evaluate our prospects; (ii) the substantial losses we have incurred and the risks of not being able to generate sufficient revenue to achieve and sustain profitability; (iii) our future success depending in large part on the growth of our target markets; (iv) our future growth depending largely on Pivotal Cloud Foundry and our platform-related services; (v) our subscription revenue growth rate not being indicative of our future performance or ability to grow; (vi) our business and prospects being harmed if our customers do not renew their subscriptions or expand their use of our platform; (vii) any failure by us to compete effectively; (viii) our long and unpredictable sales cycles that vary seasonally and which can cause significant variation in the number and size of transactions that can close in a particular quarter; (ix) our lack of control of and inability to predict the future course of open-source technologies, including those used in Pivotal Cloud Foundry; and (x) any security or privacy breaches. All information set forth in this release is current as of the date of this release. These forward-looking statements are based on current expectations and are subject to uncertainties, risks, assumptions, and changes in condition, significance, value and effect as well as other risks disclosed previously and from time to time in documents filed by us with the U.S. Securities and Exchange Commission (SEC), including our prospectus dated April 19, 2018, and filed pursuant to Rule 424(b) under the U.S. Securities Act of 1933, as amended. Additional information will be made available in our quarterly report on Form 10-Q and other future reports that we may file with the SEC, which could cause actual results to vary from expectations. We disclaim any obligation to, and do not currently intend to, update any such forward-looking statements, whether written or oral, that may be made from time to time except as required by law.

This blog also contains statements which are intended to outline the general direction of certain of Pivotal’s offerings. It is intended for information purposes only and may not be incorporated into any contract.  Any information regarding the pre-release of Pivotal offerings, future updates or other planned modifications is subject to ongoing evaluation by Pivotal and is subject to change. All software releases are on an if and when available basis and are subject to change. This information is provided without warranty or any kind, express or implied, and is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions regarding Pivotal’s offerings. Any purchasing decisions should only be based on features currently available.  The development, release, and timing of any features or functionality described for Pivotal’s offerings in this blog remain at the sole discretion of Pivotal. Pivotal has no obligation to update forward-looking information in this blog.

Update your feed preferences





submit to reddit


  • No Related Posts