Jere's Techblog

Install Consul Hashicorp trough Powershell

The Consul Hashicorp DNS service is a frequently used and modern service. Enclosed you will find a Powershell Script to install the Consul-Client as a Windows-Service. The script also allows you to run a version update.

When using the script you have to adjust the variables in line 1-13. For the update only the version number has to be adjusted, which is based on https://releases.hashicorp.com/consul/.

The script creates and updates the following config Files:
\config\consul.hcl
\config\node_exporter.json

If you don’t need this, you can comment it out of the script yourself.

0
Continue reading...

Jobs on PowerShell

Certain processes can take a long time. As an example, if you want to search a specific event log trough several servers.
To counteract this, Powershell has introduced “Jobs, Workflows and Foreach-Parallel”. It should be well estimated what you can use where best. Personally, I like to rely on jobs when it comes to remote querying / remote invocation.

There is a sensational blogpost by Harry Eagles bout the topic:

https://blogs.technet.microsoft.com/uktechnet/2016/06/20/parallel-processing-with-powershell/

I would like to show a small example of how I use Jobs to read out Eventlogs about several machines. In the example, it is only checked if the corresponding log exists or was written in the last 45 minutes. For 128 servers I needed 30 minutes with this parallel Task. I killed the sequential script after 6 hours …

0
Continue reading...

Join Azure VM into AD and install SCCM Client

Enclosed a script to join the Azure machine into AD and install the SCCM client. This is useful if you want to populate a native Azure VM that was not installed with SCCM. To make the AD-join a service user was assigned in the script, certainly not the most beautiful variant but this can be encrypted by a compiled EXE. This can be done with the following tool: https://gallery.technet.microsoft.com/scriptcenter/PS2EXE-GUI-Convert-e7cb69d5

Of course, network access to the AD and SCCM server must be available.

0
Continue reading...

local & remote msu patchfile installation with Powershell / Windows Update Standalone Installer

Windows Update Standalone Installer

The patch installation is done via wusa.exe.

The following print screen shows the parameters of the Windows Update Standalone Installer.

local installation

As far as I know, the patch cannot be installed with native powershell, means we have to address the wusa.exe in powershell. Of course Powershell is a nice way to automate the whole process.

In the following example, the patch is copied from a UNC share and installed locally.

remote installation

I was not able to run wusa.exe remotely, any tests with workflows, Remotepowershell (Invoke-Command CMDLeet) failed. Even triggering a localy copied batch file caused problems. The wusa.exe process was executed with the correct parameters but aborted after a few seconds.
Even with an Invoke-Command and the parameter -Wait it didn’t work.

Probably it’s because you intervene in the system and perform an unauthorized action.

With the PSExec.exe it is possible to start the process remotely.

The principle is very simple, you have to copy the patch to the appropriate target computer. Then PSExec starts a remote process on the target computer and executes the wusa.exe with the corresponding parameters. The wusae.exe must point to the path where the patch was copied.

And so you can distribute a patch for multiple computers with a simple iteration.

full remote automation

There are of course several ready-made scripts to install multiple patches on multiple computers. The script which I use in the company environment, I have inserted below. The code does not come from me, but from the following forum post: https://community.spiceworks.com/topic/2054098-silently-install-patches-remotely-and-reboot?page=1#entry-7246666

1+
Continue reading...

Map Share to free Driveletter

With this code snippet a share can be mapped to the next free drive letter.

It is especially useful if you have to work with a driveletter in the code or if the share has to be mapped in the Scirpt and has to be removed at the end of the script.

0
Continue reading...

Troubleshooting an App-V issue on a PVS image

This blog entry is based on the following, a little bit outdated article:

The problem is unfortunately still current it just brings some changes with Microsoft Server 2016. Therefore I took the liberty to copy some explanations from the “old article”.

Problem Description

During a recent application implementation project, we ran into the following issue. Some App-V applications, which were installed locally in the PVS image, were unable to start or they were throwing various error messages. One of the applications which were showing errors, was MS Office (Word, Excel, Powerpoint) viewer. The error thrown at startup of the application was the following: “The operating system is not presently configured to run this application.”

The App-V client was 5.0 SP2, but App-V 5.0 SP3 was also used as a troubleshooting step. The PVS target devices were configured as such:
Streamed disk
Persistent disk (flush overflow)
Re-installing the application in the image, solved the issue for that particular application. However, we wanted to know the root cause of this issue, so we logged a case at Citrix. This was done because the behavior was not existing on a regular non-streamed VM.
After extensive troubleshooting together with Citrix support we discovered the root cause:
One of the registry keys (HKLM\SOFTWARE\Microsoft\AppV\MAV\Configuration\Packages\<package ID>) containing the PackageRoot value contained a faulty HarddiskVolume number.
This volume was indicated as 3, whereas the streamed disk volume number was 2.

Solution

Correcting HarddiskVolume3 into HarddiskVolume2 did solve the issue.
The reason why the HarddiskVolume3 value got into the registry was because these applications where installed in the image on the template machine. This was the machine from which the initial vdisk was captured. During the installation of the particular App-V applications, the original disk was still attached .


This is issue is definitely not Citrix or PVS related, but can be encountered on such a setup.
To prevent this issue from happening again in the future, the original disk was detached from the template VM.

You can get the disknumber in CMD with “DISKPART -> ListDisk” or PowerShell “Get-Disk”.

My expirience and solution with this issue on Server 2016:

In our Environment we ran into the same problem and we could fix this on Server 2008R2 & Citrix 6.5, PVS 7.15 with the modification of one of the registry keys (with a Startupscript during worker boot). (HKLM\SOFTWARE\Microsoft\AppV\MAV\Configuration\Packages\<package ID>) containing the PackageRoot value contained a faulty HarddiskVolume number.

On Server 2016 (Citrix 7.17) everything was useless. Creating or deleting a disk on the masterimage or changing the RegKey didn’t work. I also didn’t find a way to change the disk volume number.

The problem could only be solved by adjusting the call parameter of the application. If the application is started in the App-V context it works fine.

As an example:

Microsoft InfoPath 2013

C:\ProgramData\Microsoft\AppV\Client\Integration\D24C3BDD-8FAD-44D3-998C-933F8F053682\Root\Office15\INFOPATH.EXE /appvve:d24c3bdd-8fad-44d3-998c-933f8f053682_6b0281c5-bb0b-49fb-b52c-a6651e8ed2ed

filetype associations fix

to fix the filetype associations you need to add the “/appvee:**APPV-ID***” parameter to the registry root class:

HKEY_CLASSES_ROOT\InfoPath.Solution.4\shell\Open\command

“C:\ProgramData\Microsoft\AppV\Client\Integration\D24C3BDD-8FAD-44D3-998C-933F8F053682\Root\Office15\INFOPATH.EXE” /appvve:d24c3bdd-8fad-44d3-998c-933f8f053682_6b0281c5-bb0b-49fb-b52c-a6651e8ed2ed “%1”

1+
Continue reading...

Reset User Profile FatClients

Just run the Script and have some fun while deleting local/remote Userprofiles 🙂

The parameters Username and ComputerName are mandatory.

The parameter -wildcard:$true allows to delete multiple profiles. For example all users with the profile name “John*“.

0
Continue reading...

Migration mounted shared Mailboxes from Outlook 2010 to Outlook 2016

During the migration from Server 2008 R2 – Citrix 6.5 to Server 2016 Citrix 7.15, the customer had a special request: that the language settings, printer mappings and Outlook shared mailboxes be transferred to the new Server2016/Office 2016 environment. Of course, we don’t want to copy the full Windowsprofile, instead we want only use the most necessary settings to keep the new profile as clean as possible.
With the printer mappings and language settings there are so far no problems, all this can be found “relatively simply” in the Registry and taken over (Powershell is your friend).

With the Outlook shared mailboxes it was more complicated…we had in this specific case no possibility to get the relation between the assigned shared mailboxes and the users trough Exchange…the Exchange admin told us that you can’t read the relations with the current Exchangeserver settings.

Although you can technically read the members of a shared mailbox with get-mailbox or a similar command.

Probably you could also mount the shared mailboxes automatically to Outlook…if you like…but honestly, that’s not the point. And
i’m not an MS-Exchange professional…😉

You can actually get Outlook profiles/mounted shared mailbox (profiles can be seen under  CMD: “c:\Windows\SysWOW64\control.exe mlcfg32.cpl“)from the user registry. It may not be the best way but it works and offers a small advantage. You migrate only those shared mailboxes which the user has assigned to himself in the current Outlook version. You will not randomly migrate all shared mailboxes to the new Outlook environment just because the user is a member of those.

To cut a long story short…
What needs to be done now to migrate the mounted mailboxes/profiles from Office 2010/Server2008R2 to Office2016/Server2016?
First an export of the Outlook profiles:
HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles

Watch your step! This cannot be imported easily…because the path has changed ( Thank you Microsoft!).

New path under Office 2016 (Import to these location):
HKCU\SOFTWARE\Microsoft\Office\16.0\Outlook\Profiles

There are a lot of cryptic registry keys but so far the migration and the Outlookprofiles hasn’t caused any problems. Write me in the comments, if you know the specific key’s which are needed to migrate shared mailboxes (so I can make everything a less streamlined and cleaner)…I don’t take this trouble today 🙂

Automation:

You have to define the $root variable, it can be something like ‘$root = “$env:appdata\Profilmigration7x”‘ or a Network share. If you use the Appdata path, ensure to Copy the data to the “NEW” appdata-path if you use Citrix or another UPM versioning tool.

0
Continue reading...