First thoughts on Technical Preview 1702 for System Center Configuration Manager

A new month, a new technical preview and new thoughts!

It is probably needless to say but “Do NOT install technical previews in your production environments!!”

Send feedback:
Technical preview 1702 introduces a new option in SCCM to send feedback or do feature requests. The home ribbon will have a feedback option but you can also klick on any object in the console. When clicking on feedback, a browser will open a link to the System Center Configration Manager Feedback site. Does this add any value to SCCM? No I do not think so! although it will be a lot easier to send feedback to Microsoft. I just hope it will not be used as a place for bashing whenever things go wrong.

Updates and Servicing:
With 1702 they have simplified the updates and servicing view. When SCCM is more than two (or more updates) behind ‘Updates and Servicing’ will only show the most recent version available. Every new update contains all previous updates so in my opinion this is a great feature. Off course you will still be able to download more previous versions but you will get a warning that it is super-seeded by a newer version. The most recent update will be downloaded automatically when available while older updates, also when not used, will be automatically deleted from the ‘EasySetupPayload’ folder.

Peer Cache improvements:
From now on, a peer cache source computer will reject a request for content when the peer cache source computer meets any of the following conditions:

  • Is in low battery mode.
  • CPU load exceeds 80% at the time the content is requested.
  • Disk I/O has an AvgDiskQueueLength that exceeds 10.
  • There are no more available connections to the computer.

I really like these new settings! They will give us more control over when devices are available for peer caching. You simply don’t want to encumber systems which are low on resources. This way your are more likely to use peer caching.

Use Azure Active Directory Domain Services to manage devices, users, and groups:
With this technical preview version you can manage devices that are joined to an Azure Active Directory (AD) Domain Services managed domain. You can also discover devices, users and groups in that domain with various Configuration Manager Discovery methods. At the moment I am not using Azure AD in combination with SCCM but this is great feature for people who are working with Azure AD.

Conditional access device compliance policy improvements:
This feature only applies to iOS and Android devices. This will help organizations to mitigate data leakage through unsecured iOS or Android apps. You have to configure the apps in a non-compliant list yourself. It will block access to corporate resources that support conditional access until the user has removed the app. Downside is that you will need to determine and configure the apps by yourself. If you are not aware of the app that could be leaking data, this feature won’t help you much. But it will certainly help blocking certain apps which you don’t want to be installed on your corporate iOS or Android devices. For example when a app uses excessive data consumption.

Antimalware client version alert:
When 20% (default) or more of your managed clients is using an outdated version of anti-malware (Windows Defender or Endpoint Protection client) Configuration Manager Endpoint Protection will generate an alert. Great feature when u are using SCEP or Windows Defender in your environment. I wonder how this is measured and in which time frame will a client be marked as outdated?

Compliance assessment for Windows Update for Business updates:
I am not going to explain what ‘Windows Update for Business Updates’ is. Therefor I would like to point you to the following technet article. From this technical preview on you can now configure a compliance policy update rule to include a Windows Update for Business assessment result as part of the conditional access evaluation.

Important: You must have Windows 10 Insider Preview Build 15019 or later to use compliance assessment for Windows Update for Business updates.

Improvements to Software Center settings and notification messages for high-impact task sequences:
This release includes the following improvements to Software Center settings and notification messages for high-impact deployment task sequences:

  • In the properties for the task sequence, you can now configure any task sequence, including non-operating system task sequences, as a high-risk deployment. Any task sequence that meets certain conditions is automatically defined as high-impact. For details, see Manage high-risk deployments.
  • In the properties for the task sequence, you can choose to use the default notification message or create your own custom notification message for high-impact deployments.
  • In the properties for the task sequence, you can configure Software Center properties, which include make a restart required, the download size of the task sequence, and the estimated run time.
  • The default high-impact deployment message for in-place upgrades now states that your apps, data, and settings are automatically migrated. Previously, the default message for any operating system installation indicated that all apps, data, and settings would be lost, which was not true for an in-place upgrade.

This is simply awesome! I believe that user communication is a key feature for a successful deployment of software, applications and releases. For complex updates I always use the Powershell App Deployment Toolkit and all of its nice features. But for more straight forward and simple deployments, which will need less communication, I can use this new feature. Hopefully they will expand it with more possibilities in the near future.

Check for running executable files before installing an application:
Again this is a great new feature which they added, too bad its only for applications in some scenarios I still use packages. But nevertheless this is a great feature which I will be going to use on a frequent base! I always had to use scripts or the Powershell App Deployment Toolkit to achieve this, this will save me a lot of work in the future! Hopefully they will expand this feature in the future for packages and task sequences and maybe add a message. A nice addition to this will be to let the users decide themselves if they want to close the process/executable before continuing or if they want to delay the installation until a pre-defined deadline.

Well these were my first thought on SCCM CB technical preview 1702 this month and I will be continuing my ‘first thoughts’ on all upcoming technical previews. If you have any thoughts yourself or any questions please post them below in the comment area.

Source: https://docs.microsoft.com/en-us/sccm/core/get-started/capabilities-in-technical-preview-1702

First thoughts on Technical Preview 1701 for System Center Configuration Manager

A few days ago Microsoft made technical preview 1701 for SCCM available for download. Here are my first thoughts on this technical preview (TP).

Boundary groups improvements for software update points
In CB 1610 Microsoft introduced  important changes to boundary groups and how they worked with Distribution Points. With TP 1701 they are taking it a step further by adding the Software Update Points role. With TP 1701 you will be able to manage which SUP a client can use and which SUP’s it can use as fallback depending on which DP it’s connected to.

Please take note that the fallback time is not yet fully supported therefor it can take upon 2 hours before a client will use it’s  fallback SUP.

This feature will be more than welcome for a client I am working with at the moment. They’ve got multiple DP’s across the country with slow WAN’s The possibility to decide which boundary group is using which SUP and fallback SUP will be a great addition.

Hardware inventory collects UEFI information
This new feature is enabled by default when TP 1701 is installed. A new inventory class (SMS_Firmware) and property (UEFI) will be filled. The UEFI property will be set to TRUE when a computer is started in UEFI mode.  This will probably be useful in some circumstances when u want to know if a device or more devices use UEFI or Legacy BIOS to boot up.

Improvements to OS deployment
Microsoft listened to the community for most of these improvements. Lets see what they are and what they can do for us.

  • Support for more application for the install Application task sequence step:
    The number of applications you can add to this step have been increased to 99 applications. Previous count was 9 applications. I still prefer using packages for my task sequences so as long as we can still use packages I probably won’t be using applications within my OSD task sequence. And I’ve never been in the situation that I needed to use them in my task sequence. That said I believe for those who do and maybe for future use it’s a good improvement.
  • Expire standalone media:
    It will be possible to optionally set start and expiration dates when you create standalone media. This will be needed when you want to expire certain deployments through standalone media when you don’t want the media to be used after and before a certain date. I don’t use standalone media that much but I can imagine it ill be useful when for example deploying certain software or operating systems for a specific time frame and you don’t want it to be used in a later stadium or before a specific date.
  • Support for additional content in stand-alone media:
    It used to be only possible to add content which was referenced to the task sequence while creating standalone media. With TP 1701 it will be possible to add additional packages, driver packages and applications on the media. This could come in handy when u want to launch additional software and/or scripts after the task sequence is ended. I can imagine combining this with a script launched by the “SMSpostAction” feature which was added in SCCM 2012 R2 a while ago. I wrote a blogpost (linkabout this variable which you can set during your task sequence.
  • Configurable timeout for Auto Apply Driver task sequence step:
    I almost never use the step “Auto Apply Drivers” within a task sequence. I prefer using a tool from the hardware supplier for installing drivers. This way the drivers are installed the way it’s meant to be installed by the supplier. Most big hardware suppliers like DELL, HP and Fujitsu have their own SCCM or command line tooling for installing their drivers. But if you don’t have a choice and/or you prefer to use this step Microsoft added a foursome variables to timeout this step, values are in seconds.

    • SMSTSDriverRequestResolveTimeOut Default: 60
    • SMSTSDriverRequestConnectTimeOut Default: 60
    • SMSTSDriverRequestSendTimeOut Default: 60
    • SMSTSDriverRequestReceiveTimeOut Default: 480

     

  • Package ID is now displayed in the task sequence step:
    Any task sequence step that references a package, driver package, operating system image, boot image, or operating system upgrade package will now display the package ID of the referenced object. When a task sequence step references an application it will display the object ID. This is a great feature, I really love this. This will make troubleshooting the task sequence easier and its just a small change. You don’t have to search for the specific ID first before you go search in your logs. I see myself combining this with the variable “SMSTSErrorDialogTimeout” set to 0 (forever) so I can quickly see which package/object ID is involved when my task sequence is failing.
  • Windows 10 ADK tracked by build version:
    For example if the site has Windows ADK for Windows 10, version 1607 installed, you won’t be able to edit boot images other than 10.0.014393 in the SCCM console. I can imagine that this will become less practicable when you want to troubleshoot with different versions of boot image versions.
  • Default boot image source path can no longer be changed:
    I always use custom boot images and it will still be possible to adjust the source path for custom boot images. I see no problems with this adjustment and I think it will be a nice addition that you can always find your default boot images on a fixed location.

Host software updates on cloud-based distribution points
Since you can download software updates directly from Microsoft Update this new feature isn’t that appealing. But I believe the feature set for cloud-based distribution points will grow in the near future and it will  become more practicable to use cloud-based distribution points in the future.

Validate device health attestation data via management points
“Beginning with this preview version, you can configure management points to validate health attestation reporting data for cloud or on-premises health attestation service. A new Advanced Options tab in the Management Point Component Properties dialog box lets you Add, Edit, or Remove the On-premises device health attestation service URL.”
I haven’t used DHA before and it was first introduced in Windows 10 version 1507. For more information about DHA I suggest to read the following Microsoft Article (link).

Use the OMS connector for Microsoft Azure Government cloud
With this technical preview, you can now use the Microsoft Operations Management Suite (OMS) connector to connect to an OMS workspace that is on Microsoft Azure Government cloud. I love OMS, nothing more to add.

Android an iOS versions are no longer targetable in creation wizards for hybrid MDM
Beginning in this technical preview for hybrid mobile device management (MDM), you no longer need to target specific versions of Android and iOS when creating new policies and profiles for Intune-managed devices. Instead, you choose one of the following device types:

      • Android
      • Samsung KNOX Standard 4.0 and higher
      • iPhone
      • iPad

It’s always nice to see things get more simplified and this is one of them!

Source and more information: https://docs.microsoft.com/en-us/sccm/core/get-started/capabilities-in-technical-preview-1701

Migrate App-V Usersettings

This blog is about migrating settings from an App-V 4.x package to any other installation. Is it possible if you leave the settings location the same? I think it is.

First a little intro about my thought’s on settings. When you work as an Application administrator or Application packager you often think about application settings. The settings control the connections to a Database, fileserver, backendserver, data save locations and settings that users want to create for themselves.

You can help your enduser, and yourself, by thinking about these settings in advance. Server settings, company settings and datapath’s  should be predefined when a user fist starts the application. Most of the times these settings are saved in the Registry, ini files and configfiles. Alluser config can be found in the HKLM part of the registry or the installfolder. Usersettings wil be saved in HKCU or Appdata folder. Of course, this all depends on the application.

How to control the user settings depends on the type of package you use and what kind of environment you are packaging for. Most commonly used packaging ways are;

  • App-V, settings are recorded and sometimes controlled by prelaunch scripts
  • MSI, Settings are recorded and sometimes controlled by Custom actions
  • Local installations (setup.exe), settings can be created by using response files or can be set by install-scripts, Group Policies Preferences etc.
  • The backend server contains userprofiles with settings.

If you have an environment with Immidio Flex, RES workspace manager, Microsoft UE-V or another solution that can manage your settings you should use them. In this case you can leave you package clean and manage the settings  for you client application by your solution.

But now back to App-v , without a user environment tool. When you create an app-v package you can predefine some settings. You should turn off autoupdates, configure licensefiles, serverconnections and the default data path for the users data files if possible.  This way, the user isn’t bored by these configure actions. Currentuser settings can be done by a prelaunch script.

If the user changes settings after launching the application, like the color of the text, this is saved in the userprofile. The settings are saved in an PKG file. This file can’t be read but will contain al the changes a user makes. This file will roam with the user to any system where the same App-V package is started.

This works great. The problem starts when a major application upgrade or change occurs. Think about.

  • New software version (when update package isn’t the way)
  • Converting from App-V to a MSI (local install). Yes it happens..
  • Migrating to App-V 5

Of course you should predetermine all the common settings. But settings changed by the user, which all  will be stored in the PKG file, will be gone when changing and/or upgrading! The user will not be pleased with this result.

How can we make this easier for the user?

  • Sometimes we cannot. Maybe the new version can’t deal with the settings from the old version..
  • With tools that can manage usersettings (Microsoft UEV, Immidio Flex, RES workspace manager)
  • With scripts

I created this post for environments without a user setting management tool. My solution is creating an App-V shutdown powershell script. Of course this must be adapted to your application needs. So the idea is.

  • On application shutdown export the settings to the user homedir
  • Configure the new application to import the settings from the user homedir (once)

For example, my customer has an application that appears to run badly within App-V with a certain version. A new package/installation is created. But while testing the users did lose a lot of settings.  It appears that the user can do a lot of personal tweaking in the application. So I created the following.

Environment:
-App-V 4.6

Application settings:

Managed by App-V client (PKG)

Settings that must be migrated

AppData\MyApp\UserFiles
HKCU\Software\MyApp\UserSettings

Step 1: Export the settings from the old package

In the OSD file from the old package add the following code

<DEPENDENCY> <SCRIPT EVENT="SHUTDOWN" TIMING="POST" PROTECT="TRUE" WAIT="TRUE" TIMEOUT=""> <HREF>"powershell.exe" -file .ExportSettings.ps1"</HREF> </SCRIPT> </DEPENDENCY>

The Exportscript can be placed on any place. Maybe the best way is placing it within the package on the app-v drive.

Step 1a: The export script

Steps are:

  • Export AppData\Application1\UserFiles\
  • Export HKCU\Software\ Application1\UserFiles\UserSettings
  • Create logfile

Step 2a: Import the settings into the new package

Add the following in you new app-v package (or start up script for local installs..)

<DEPENDENCY> <SCRIPT EVENT="LAUNCH" TIMING="POST" PROTECT="TRUE" WAIT="TRUE" TIMEOUT=""> <HREF>"powershell.exe" -file .ImportSettings.ps1 "-</HREF> </SCRIPT> </DEPENDENCY>

Step 2b: The import script

Steps are:

  • Import if check file doesn’t exist AppData\Application1\UserFiles\
  • Import if check file doesn’t exist HKCU\Software\ Application1\\UserFiles\\UserSettings
  • Create logfile and checkfile.

ImportSettings.ps1 content

App-V 5

In my next post I will test this solution in App-V 5. My guess is that it wil work. App-V 5 stores usersettings in:

%appdata%\Microsoft\appV
and
HKCU\Software\Microsoft\AppV

But when you start the application the settings are translated. So, appdata will become the normal appdata location. But it will only exist if the package is started. So the trick is “Run the importscript when the package is started but BEFORE the application is launched”. So I need to figure out how the pre-launch script works in App-V 5.

To be continued…

Cheers

Silent uninstall of password protected TrendMicro antivirus

Ever tried to silently uninstall the TrendMicro AntiVirus client when it’s password protected? You probably could not find a suitable, free and total solution for your situation. It happened to me a while ago and I would like to share my experiences. I know it’s possible to manage the installed clients through the TrendMicro server management console, but at the company where I implemented this solution they chose not to because of the limited bandwidth to certain company locations.

 Environment description:

  • Windows 2008 R2
  • Window 7
  • SCCM 2007 R2
  • RES Workspace Manager 2011 SR2
  • App-V 4.6 SP1
  • TrendMicro v10.5+

The challenge:

Before installing the new version of the TrendMicro AV client the old client needs to be uninstalled. When I tried uninstalling the client with “msiexec.exe /x{guid} /qn /norestart” I noticed that the the uninstallation failed. At that point I discovered that the uninstallation required a password. The uninstall will be a part of a SCCM 2007 “Task Sequence” which  will contain multiple software updates and contains one reboot at the end.

Requirements:

  • Workarround for the Password protection
  • No Reboot until planned reboot
  • Silent Uninstall

Solution:

Searching the internet for a solution I didn’t find any working method to bypass the password protection and/or silently uninstalling the AV client. It seemed that the only solution was to manage the clients through the TrendMicro AV Management Console. Like mentioned earlier this was not an option. I needed to look for another solution. After some searching I came across the AUTOPCC.ini file on the TrendMicro management Server: AUTOPCC.ini located in:

“X:\Program Files (x86)\Trend Micro\OfficeScan\PCCSRV\Autopcc.cfg”

Here I found the values -991334* (no password) and -0442* (silent uninstall).
I discovered that these parameters worked in combination with “ntrmv.exe” which is located in the following location on the client side:

“C:\program Files\Trend Micro\OfficeScan Client\”

(*) I’ve recently changed these parameters for security reasons, if your not able to find these parameters on the location I mentioned. You are probably not authorized to uninstall the TrendMicro AV

By using these parameters in combination with “ntrmv.exe” the uninstall ignores the password protection and uninstalls the TrendMicro client silently without rebooting.

I created a script for the uninstall. In this script I prevented that the installation of the new client would start before the uninstall of the old client is completed. To achieve this I added a check in the script. It will check if the “ntrmv.exe” process is still running, if so it will keep on checking untill the process has stopped. Than the script will finish.  Underneath the code of the vbs script I created.

Underneath a version which will check if it’s a x86 or x64 installation;

After the uninstall I checked if there was anything left behind. As well as the installation folder as the TrendMicro registry-tree were completly deleted during the uninstall.

If you’ve got any comments or questions please post them below if not I hope this information was useful for you.

Windows 7 and error "Could not connect to the System Event Notification Service"

At the moment I work at a company with about 8000 to 9000 workstations. A couple of users called in an issue that they had trouble logging in into Windows 7. Once in a while they got the following error message during the logon process.

“Windows could not connect to the Event Notification Service service. Please consult your System Administrator”

 

Only one or more reboot(s) seemed to bypass the error. This was not an acceptable situation and I was asked to look into this problem.

Environment description:

  • Windows 2008 R2
  • Window 7
  • SCCM 2007 R2
  • RES Workspace Manager 2011
  • App-V 4.6 SP1

Underneath a screenshot of the error message:

System-Event-Notification-Service

After checking the event viewer I noticed that not only the “System Event Notification Service” was failing but also several other services failed to start. Underneath a list of services that are involved.

  • Certificate Propagation
  • Extensible Authentication Protocol
  • Group Policy Client
  • IKE and AuthIP IPsec Keying Modules
  • IP Helper
  • Server
  • Multimedia Class Scheduler
  • User Profile Service
  • Task Scheduler
  • System Event Notification Service
  • Shell Hardware Detection
  • Themes
  • Windows Management Instrumentation

With the knowledge that not only the “System Event Notification Service” service was failing to start I searched the web for a solution. I found several articles but they didn’t solve my problem. Than I stumbled onto the following Hotfix:

http://support.microsoft.com/kb/2590550/en-us?fr=1

This hotfix solved my problem. But in the meanwhile several users were still experiencing this problem. Due a backlog on the change management side, it would take a while to get this hotfix in production. I decided to look for a workaround for the customers who were experiencing this problem more frequently.  It seemed, like described in the article, that the “Microsoft Virtualization client” had something to do with it. I quote:

Cause: This issue occurs when a new drive is added to the system while background services are still starting.  The most common example of this is with Microsoft Application Virtualization Client.  When this service starts, it creates a virtual drive.  When this drive is created during system startup, the Server service may crash the shared service host process.  This process contains other services which are important for completing user logins.  When these services fail at startup, a blue or black background image is displayed instead of the user’s desktop.

When trying to find a workaround I found that delaying the startup of the “Microsoft Virtualization Client” service seemed to work. This should give the other services time to start-up. It’s a quick and dirty method but it did solve the problem for the users who were experiencing this problem on a frequent base. We decided to use it as a temporally workaround until the hotfix was applied.

The hotfix is also applicable for Windows Server 2008 R2 in case you are experiencing the same issues on a server.

Greetings,

How to Launch Vapplauncher with Parameters using powershell

Hello everybody,

At the moment I am working in an environment where App-V is integrated in SCCM 2007. To launch an App-V application the “Vapplauncher” is used. This week I have been asked to package an application with the following requirements.

 

 

The application must be able to start from a Scheduled Task and External Application.

  • The application must start with different parameters.
  • The parameters can change every month and this should be done by the “Super user” (Which has no access to App-V / SCCM)

Starting the App-V application from a schedule or external application is just pasting the Vapplauncher command line into it. However, the Vapplauncher doesn’t accept any parameters. This is why you have to create a extra OSD with the parameters in it. This means that the “Super user” has to change this OSD each month and deploy it through SCCM. Of course this was not an option because of the rights.

The challenge:

  • Start the application with the parameters through: C:\WINDOWS\system32\CCM\VAppLauncher.exe /launch “MyApp”
  • The user must be able to change the parameters each month without having to change the OSD or having special rights.

Solution:

  • Create a networkshare where the user has enough rights to change/write files
  • Place a *.txt file in the share containing the parameters
  • Create a PowerShell script (or more if needed) in the share which can do the following:
  1. Get the content of the *.txt file
  2. Start the application with the parameters found in the *.txt file which is edited by the user
  • Create an OSD to start the PowerShell script
  • Give the user the command line to start the OSD so it can be used in a schedule or External application

Components of the solution:

Networkshare: G:\MyApp\Test\
*.txt file for user: G:\MyApp\Test\MyApp_parameters.txt
PowerShell script: G:\Myapp\test\Script\Start_Myapp.ps1
App-V package: With at least one OSD that starts the application with the powershell script

The powershell script:

These are the basics of the script. Of course you should adept it to your needs with logging and checking on existing files etc. But now you will have a start.

This is the starting line you should use in the OSD:

The command line to start the application is:

Thank you for reading. I hope it will be useful for you. If you have any comments or questions you can use the comments underneath or the PM system to ask questions.

Greetings,

Joey Steenstra

SCCM 2007 R2 Error unregistering notification query CcmExec

Not to long ago we had some issues (re)deploying Windows 7 (including the baseline) on our client systems.  One out of three systems failed during (re)deployment.  At first we thought it was because the systems were not removed correctly from SCCM before redeployment. Further investigation told us that the deployment also failed on new systems and systems which were correctly removed from SCCM before redeployment.

Environment description:

  • Windows 2008 R2
  • Window 7
  • SCCM 2007 R2
  • RES Workspace Manager 2011
  • App-V 4.6 SP1

Description:

CcmExec.log logged the following:

“Error unregistering notification query CcmExec“ occurs after a restart initiated by the installation of the App-V client. It seems that CcmExec (SMS Agent Host  service) is having trouble to start. After a while it times out and the (re)deployment fails. The restart which is needed after the installation of the App-V client is the first restart initiated by an application after the windows installation. It could be possible that this error also occurs after other installations where a reboot is needed. Unfortunately we haven’t run tests on this, we only have one installation which needs a reboot during this phase.

Solution:

By delaying the auto startup of the CcmExec service we solved the (re)deployment issues in this case. The CcmExec service will start after all other services who are configured as “Automatic” startup. Normally this is used to shorten the boot time but in this case it also helps us preventing (re)deployment failures. Right before the installation of the App-V client we added a “Run command line” to the task sequence as follows.

Type: Run Command Line
Name:  Delay startup CCMexec service
Description: Delay CCMexec (SMS Host Agent) service
Command line:

Before the last action of our task sequence will take place, in our case a last reboot to complete the deployment, we added the following “Run Command Line”.

Type: Run Command Line
Name:  Automatic startup CCMexec service
Description: Sets CCMexec (SMS Host Agent) service on automatic start without delay
Command line:

This was our solution for the (re)deployment problem we encountered and hopefully it will help some of you who experience the same problems. If you have any comment or questions you can post them down below in the comment section.

Greetings,

Marco Nuijens