Blog – Page 6 – Virtual Engine Ltd

16th January 2012

Locating Computer GPO Registry Values

I come across this scenario all the time that requires a HKLM registry setting to be configured. Typically this can be implemented via Group Policy but, for whatever reason, you which to set the resulting registry value directly. It might be because you don’t wish to cut a new GPO just for a couple of servers or workstations. A common requirement is to set the RDS licensing server as part of an automated deployment. Maybe you use RES Automation Manager like we do. However, this scenario is not limited to just RES Automation Manager. You could use the information in this post to configure a few specific settings as part of a WDS deployment for example.

Hopefully by now you are all familiar with the free Virtual Engine Toolkit (VET). No!? Shame on you! I suggest you take a look over here and see how it can help migrate from a unmanaged user environment to a managed one.

So you now know VET is especially good at converting user related GPOs into .REG files that can be imported in your UV/UEM tool of choice i.e. RES Workspace Manager or AppSense Environment Manager. One of VET’s hidden talents (and undocumented until now) is we can also convert computer related GPO’s into .REG files.

Using the settings above as an example I’ll run you through how we achieve this with RES Automation Manager and not in a GPO. If you’ve read our series on user GPO migration then you’re aware that GPO settings (not all!) are just registry settings. The problem we normally have, is where and what should these values be set to?

You could at this point download the Microsoft Group Policy Settings Reference guide and find the individual registry keys. You could use the Group Policy Search which Kees Baggerman spotted and pointed out in this blog post Winking smile . You can spend time Googling them at which point you would have to start manually adding them to the registry task in AM. But its much, much simpler to use VET!

NOTE: the same process could be used for migrating multiple existing computer related GPOs into AM but please be aware that the computer will probably need a reboot before the targeted settings come into force.

First thing to we need to do is create a Dummy GPO where we can set the various policies we’d like included in AM. In my example I’ve called my GPO “Dummy GPO for VET” and configured the settings we’d like to apply as in our example above.
Next we need to launch VET and use the “Convert Group Policy Objects Wizard” to scan the SYSVOL folder for our newly created/existing GPO. Once VET displays the list of GPOs select the one that you wish to convert then click “Next”
.
Select “Use subfolders for User and Machine policies”. Deselect “Also create RES Workspace Manager Building Block Files” then click “Next”, “Next” and “Finish”.
Looking in the “Documents\Machine” folder you’ll find the newly created .REG File containing our settings.
Now launch the RES AM console and create a new module which contains the “Registry Settings (Apply)” task. Its then a case of importing the .REG File created previously; so you should end up with something looking like this.

It’s as simple as that! We’ve used a dummy GPO that is not applied to any computer objects, set our required settings and imported the exact resultant registry values into RES Automation Manager. You can probably think of other great use cases for this too.

You never know we might incorporate the ability for VET to generate RES Automation Manager building blocks in the future.. Hope this little gem helps someone in the future like it has me!

Nathan

11th January 2012

The case of the missing Office 2007 Quick Access Toolbars

Recently I’ve been involved with one of our customers who is migrating from RES PowerFuse 2008 and roaming profiles on XenApp to RES Workspace Manager 2011 (WM) utilising Zero Profile Technology (ZPT) and a mandatory profile.

One of the issues they had on the new environment was the Office 2007 Quick Access Toolbars (QAT) weren’t being captured by WM using the built-in templates provided which capture the locations set out below:

Windows XP and Windows Server 2003 (v1 profiles):
%USERPROFILE%\Local Settings\Application Data\Microsoft\Office

Vista, Windows 7 and Windows Server 2008 (v2 profiles):
%USERPROFILE%\Appdata\Local\Microsoft\Office

So everything appeared to be configured correctly; but still the QAT files weren’t being captured or worse still weren’t being saved in those locations.

Upon further investigation the QAT files where actually being saved in ‘%APPDATA%\Microsoft\Office’ which seemed very odd to me as I was sure one of the problems that people found when using roaming profiles with Office 2007 was the QAT didn’t roam!. This led me into thinking that maybe Microsoft had at some point released a hotfix that did in fact allow the QAT files to roam. So lets turn to the interweb and see what that brings up, and low and behold, Microsoft did just that and released a hotfix http://support.microsoft.com/kb/958062 (included in Office 2007 SP2). Setting the registry key as described in the Microsoft article forces the QAT files to be saved in the users profile which would then allow them to roam.

Once I had this vital information I quickly found that this particular customer had uncovered this fix and had implemented it using RES PowerFuse 2008 (clever boys/gals!!). Because we had copied and upgraded the RES PowerFuse 2008 datastore to WM 2011, this user registry setting was being applied to the new environment. To resolve the problem we simply removed that registry setting and let the power of the templates supplied with RES WM 2011 do their thing and capture the QAT files in the default location.

NOTE: One thing I will add about the supplied templates is they don’t capture the QAT files for Outlook 2007 i.e. Olkaddritem.qat, Olkapptitem.qat, Olkdistitem.qat, Olklogitem.qat, Olkmailitem.qat, Olkpostitem.qat and Olktaskitem.qat.

To resolve this issue you can add file filter ‘%LOCALAPPDATA%\Microsoft\Office\Olk*.qat’ to the capture settings for Outlook 2007. Hopefully this will get rolled into the default Office 2007 application templates by RES in a future release.

Hope this helps.

Nathan

30th December 2011

Active Setup – Stubpath Command Lines

I spend a lot time working with mandatory profiles and RES Workspace Manager, especially when using Citrix XenApp or Remote Desktop Services. One of the key elements to creating a slick mandatory profile is to ensure the Active Setup keys are added to the mandatory profile or you will forever see the annoying “Personaliz(s)ing Settings” message. We have covered how to do this in a previous post here by using our great free tool the Virtual Engine Profile Update Utility (PuU).

While you can merge these Active Setup Keys to stop the message box appearing; this isn’t actually where the story ends. Behind some Active Setup Components there is a command line (Stubpath) that needs to run once per user i.e. for new users logging on for the first time (for a great explanation of Active Setup, check out Helge Klein’s write up here). The drawback of just merging these keys will be that the command line (Stubpath) will not run for any user. This could have undesirable results as mentioned in the RES Blog post here and Andrew Morgan’s Blog post here.

So the purpose of this blog is really for informational purposes above anything else and to detail the most common Active Setup components containing Stubpaths, by OS. Should you need this information, it’s here for reference. For example, if you disable the ActiveSetup option within RES Workspace Manager or merge the ActiveSetup keys using the Profile Update Utility (PuU), you may have to reinstate a particular action if it causes issues (like Andy’s issue). The command line (Stubpath) is highlighted in yellow and can be used to remedy the situation if necessary:

UPDATE : Windows 8 Consumer Preview (Subject to Change) – Yes ActiveSetup is still here!

{2C7339CF-2B09-4501-B3F3-F3508C9228ED}
Themes Setup
%SystemRoot%\system32\regsvr32.exe /s /n /i:/UserInstall %SystemRoot%\system32\themeui.dll

{44BBA840-CC51-11CF-AAFA-00AA00B6015C}
Microsoft Windows (MailNews)
"%ProgramFiles%\Windows Mail\WinMail.exe" OCInstallUserConfigOE

{6BF52A52-394A-11d3-B153-00C04F79FAA6}
Microsoft Windows Media Player
%SystemRoot%\system32\unregmp2.exe /FirstLogon

{89820200-ECBD-11cf-8B85-00AA005B4340}
Windows Desktop Update
regsvr32.exe /s /n /i:U %SystemRoot%\System32\shell32.dll

{89820200-ECBD-11cf-8B85-00AA005B4383}
Web Platform Customizations
C:\Windows\System32\ie4uinit.exe -BaseSettings

{89B4C1CD-B018-4511-B0A1-5476DBF70820}
DOTNETFRAMEWORKS
C:\Windows\System32\Rundll32.exe C:\Windows\System32\mscories.dll,Install

>{22d6f312-b0f6-11d0-94ab-0080c74c7e95}
Microsoft Windows Media Player
%SystemRoot%\system32\unregmp2.exe /ShowWMP

>{26923b43-4d38-484f-9b9e-de460746276c}
Internet Explorer
C:\Windows\System32\ie4uinit.exe -UserIconConfig

>{60B49E34-C7CC-11D0-8953-00A0C90347FF}
Browser Customizations
"C:\Windows\System32\rundll32.exe" "C:\Windows\System32\iedkcs32.dll",BrandIEActiveSetup SIGNUP

>{ABB824FE-FBBE-464D-9AAA-FAFED848BF41}
IE History
C:\Windows\System32\ie4uinit.exe -UpgradeOldHistoryEntries

Windows XP

{2C7339CF-2B09-4501-B3F3-F3508C9228ED}
Themes Setup
%SystemRoot%\system32\regsvr32.exe /s /n /i:/UserInstall %SystemRoot%\system32\themeui.dll

{44BBA842-CC51-11CF-AAFA-00AA00B6015B}
NetMeeting 3.01
rundll32.exe advpack.dll,LaunchINFSection C:\WINDOWS\INF\msnetmtg.inf,NetMtg.Install.PerUser.NT

{5945c046-1e7d-11d1-bc44-00c04fd912be}
Windows Messenger 4.7
rundll32.exe advpack.dll,LaunchINFSection C:\WINDOWS\INF\msmsgs.inf,BLC.QuietInstall.PerUser

{6BF52A52-394A-11d3-B153-00C04F79FAA6}
Microsoft Windows Media Player
rundll32.exe advpack.dll,LaunchINFSection C:\WINDOWS\INF\wmp11.inf,PerUserStub

{7790769C-0471-11d2-AF11-00C04FA35D02}
Address Book 6
"%ProgramFiles%\Outlook Express\setup50.exe" /APP:WAB /CALLER:WINNT /user /install

{89820200-ECBD-11cf-8B85-00AA005B4340}
Windows Desktop Update
regsvr32.exe /s /n /i:U shell32.dll

{89820200-ECBD-11cf-8B85-00AA005B4383}
Internet Explorer
C:\Windows\System32\ie4uinit.exe -BaseSettings

{89B4C1CD-B018-4511-B0A1-5476DBF70820}
DOTNETFRAMEWORKS
C:\Windows\system32\Rundll32.exe C:\Windows\system32\mscories.dll,Install

<{12d0ed0d-0ee0-4f90-8827-78cefb8f4988}
Internet Explorer Version Update
C:\WINDOWS\system32\ieudinit.exe

>{22d6f312-b0f6-11d0-94ab-0080c74c7e95}
Microsoft Windows Media Player
C:\WINDOWS\inf\unregmp2.exe /ShowWMP

>{26923b43-4d38-484f-9b9e-de460746276c}
Internet Explorer
C:\WINDOWS\system32\ie4uinit.exe -UserIconConfig

>{60B49E34-C7CC-11D0-8953-00A0C90347FF}
Browser Customizations
"C:\Windows\System32\rundll32.exe" "C:\Windows\System32\iedkcs32.dll",BrandIEActiveSetup SIGNUP

>{60B49E34-C7CC-11D0-8953-00A0C90347FF}MICROS
Browser Customizations
RunDLL32 IEDKCS32.DLL,BrandIE4 SIGNUP

>{881dd1c5-3dcf-431b-b061-f3f88e8be88a}
Outlook Express
%systemroot%\system32\shmgrate.exe OCInstallUserConfigOE

Windows 7 32bit

{2C7339CF-2B09-4501-B3F3-F3508C9228ED}
Themes Setup
%SystemRoot%\system32\regsvr32.exe /s /n /i:/UserInstall %SystemRoot%\system32\themeui.dll

{44BBA840-CC51-11CF-AAFA-00AA00B6015C}
Microsoft Windows (MailNews)
"%ProgramFiles%\Windows Mail\WinMail.exe" OCInstallUserConfigOE

{6BF52A52-394A-11d3-B153-00C04F79FAA6}
Microsoft Windows Media Player
%SystemRoot%\system32\unregmp2.exe /FirstLogon /Shortcuts /RegBrowsers /ResetMUI

{89820200-ECBD-11cf-8B85-00AA005B4340}
Windows Desktop Update
regsvr32.exe /s /n /i:U shell32.dll

{89820200-ECBD-11cf-8B85-00AA005B4383}
Web Platform Customizations
C:\Windows\System32\ie4uinit.exe -BaseSettings

{89B4C1CD-B018-4511-B0A1-5476DBF70820}
DOTNETFRAMEWORKS
C:\Windows\system32\Rundll32.exe C:\Windows\system32\mscories.dll,Install

>{22d6f312-b0f6-11d0-94ab-0080c74c7e95}
Microsoft Windows Media Player
%SystemRoot%\system32\unregmp2.exe /ShowWMP

>{26923b43-4d38-484f-9b9e-de460746276c}
Internet Explorer
C:\Windows\System32\ie4uinit.exe -UserIconConfig

>{60B49E34-C7CC-11D0-8953-00A0C90347FF}
Browser Customizations
"C:\Windows\System32\rundll32.exe" "C:\Windows\System32\iedkcs32.dll",BrandIEActiveSetup SIGNUP

Windows 2008 R2 SP1 with Desktop Experience Installed

{2C7339CF-2B09-4501-B3F3-F3508C9228ED}
Themes Setup
%SystemRoot%\system32\regsvr32.exe /s /n /i:/UserInstall %SystemRoot%\system32\themeui.dll

{44BBA840-CC51-11CF-AAFA-00AA00B6015C}
Microsoft Windows (MailNews)
"%ProgramFiles%\Windows Mail\WinMail.exe" OCInstallUserConfigOE
"%ProgramFiles(x86)%\Windows Mail\WinMail.exe" OCInstallUserConfigOE

{6BF52A52-394A-11d3-B153-00C04F79FAA6}
Microsoft Windows Media Player
%SystemRoot%\system32\unregmp2.exe /FirstLogon /Shortcuts /RegBrowsers /ResetMUI

{89820200-ECBD-11cf-8B85-00AA005B4340}
Windows Desktop Update
regsvr32.exe /s /n /i:U shell32.dll

{89820200-ECBD-11cf-8B85-00AA005B4383}
Web Platform Customizations
C:\Windows\System32\ie4uinit.exe -BaseSettings
C:\Windows\SysWOW64\ie4uinit.exe -BaseSettings

{89B4C1CD-B018-4511-B0A1-5476DBF70820}
DOTNETFRAMEWORKS
C:\Windows\system32\Rundll32.exe C:\Windows\system32\mscories.dll,Install
C:\Windows\SysWOW64\Rundll32.exe C:\Windows\SysWOW64\mscories.dll,Install

{A509B1A7-37EF-4b3f-8CFC-4F3A74704073}
Applying Enhanced Security Configuration (Admin)
"C:\Windows\System32\rundll32.exe" "C:\Windows\System32\iesetup.dll",IEHardenAdmin
"C:\Windows\SysWOW64\rundll32.exe" "C:\Windows\SysWOW64\iesetup.dll",IEHardenAdmin

{A509B1A8-37EF-4b3f-8CFC-4F3A74704073}
Applying Enhanced Security Configuration (User)
"C:\Windows\System32\rundll32.exe" "C:\Windows\System32\iesetup.dll",IEHardenUser
"C:\Windows\SysWOW64\rundll32.exe" "C:\Windows\SysWOW64\iesetup.dll",IEHardenUser

>{22d6f312-b0f6-11d0-94ab-0080c74c7e95}
Microsoft Windows Media Player
%SystemRoot%\system32\unregmp2.exe /ShowWMP

>{26923b43-4d38-484f-9b9e-de460746276c}
Internet Explorer
C:\Windows\System32\ie4uinit.exe -UserIconConfig
C:\Windows\SysWOW64\ie4uinit.exe -UserIconConfig

>{60B49E34-C7CC-11D0-8953-00A0C90347FF}
Browser Customizations
"C:\Windows\System32\rundll32.exe" "C:\Windows\System32\iedkcs32.dll",BrandIEActiveSetup SIGNUP
"C:\Windows\SysWOW64\rundll32.exe" "C:\Windows\SysWOW64\iedkcs32.dll",BrandIEActiveSetup SIGNUP

Should anyone wish to expand on what each Active Setup Component does please feel free to leave a comment I’ll update the blog accordingly; some are more obvious than others Winking smile .

Enjoy

Nathan

29th November 2011

RES AM Passing Values Between Scripts

You don’t need to be told how great RES Automation Manager, but there are some things that we can only achieve via scripts; be it VBscript or PowerShell. In my example, it is scripting XenDesktop and XenServer for the demo showcase platform (more on this at a later date). There is currently no way to automate these products without using scripts. Unfortunately (for me) it’s always been problematic to pass values in and out of scripts to other modules. We can certainly pass a value into a script, but then we can’t return it to be used elsewhere.

My problem required creating an AD user (not via the built in task) in one script and then passing the username/password into another script. To overcome this particular issue, I started down the route of temporarily writing the information to the registry so that it could be read by the other script later in the Project. This is where I stumbled across a little gem hidden in RES Automation Manager. I don’t know whether it’s intentional and/or undocumented, but it certainly works!

I attempted to use a Parameter using the built-in @[REGISTRY] Function. In essence this instructs the RES Automation Manager agent to populate the Parameter with the contents of the registry key. This bit is simple to understand and you probably already knew this. However, what I didn’t realise is that this Parameter is updated/re-evaluated at every task within a Module. I assumed that it would only be evaluated when the Module is invoked by the RES AM agent. I’m certainly glad that this is not the case as we can now write values to the registry and AM will automatically pass the updated value to the next Task(s).

[wpdm_file id=8]

Here is an example building block that contains a single module with a single registry-based, emtpy Parameter value. The first script writes the current date to temporary location in the registry (just so happens to be where RES Automation Manager is reading the Parameter value from). The second script receives its Parameter value from RES AM (not directly from the registry within the script), adds a day (in US format!) and writes it back to the registry. The final task displays a pop-up message with tomorrows date from the RES AM Parameter.

What this does prove is that the Parameter is re-evaluated before each task is executed and therefore passed through all tasks. Never in this example module do we enter the date. Here is the status of the parameter before and after each task.

Task 1 – BEFORE: <Empty>, AFTER: <Empty> (We write today’s date to the registry, but it’s not re-evaluated until the next task)
Task 2 – BEFORE: <Current Date>, AFTER: <Current Date> (We write tomorrow’s date to the registry, but it’s not re-evaluated until the next task)
Task 3 – BEFORE: <Tomorrow’s Date>, AFTER: <Tomorrow’s Date>

I’m sure you can think of more ingenious ways of using this functionality. Enjoy! Iain

31st October 2011

Virtual Engine Toolkit v1.0 Released

We are pleased to announce that the free Virtual Engine Toolkit (VET) 1.0 has been released! The new release includes an updated wizard to convert multiple Group Policy Objects to .REG files in a single pass and also includes the new Profile Update Utility (PuU). For more information or to download now, visit the VET page on the Virtual Engine web site.

1st August 2011

BigHand Digital Dictation and RES Automation Manager – License file update

Following on from the BigHand Digital Dictation and RES Automation Manager – BHF File Locations post, I’ll show you how easy it is to update the BigHand license files across all BigHand servers in your estate with RES Automation Manager.

Managing your BigHand Digital Dictation system using RES Automation Manager

BigHand is a powerful dictation product used in many environments, but most prevalent in the Legal and Medical sectors. With enhancements such as speech recognition and workflows more and more users are relying on this business critical tool. In these posts I will go through the automation of two of the most common tasks required on the system; Updating license files and locating a dictation file.

Update license files

License files are supplied by BigHand as a .lic file. They must be located in a particular location on every BigHand server in your environment. If you have a BigHand file store server in every site, BigHand gateway for telephony or Mobile client there can quickly become lots of servers requiring a license file, this is a time consuming process which can easily be automated and here’s how.

Stop services
All the BigHand services should be stopped before you can update the license file. These need to be done in a particular sequence. For this you can use Service properties (Manage) task in the Configuration folder.

Stop Branch site BigHand services (If you only have 1 BigHand server you can ignore this)
a. On the settings tab select Change Service State
b. In service name enter BigHand Server x.x (where x.x is the version number) or you can connect to the server using the browse button and select the service
c. In New Service State select Stop service.
d. You need to set a condition on this task so that it only runs for branch sites, so select the condition tab.
e. Under expressions select Add and then Registry Setting
f. Click the browse button next to the Operand field and connect to your Master BigHand server’s registry. Drill down to the following key and double click: HKEY_LOCAL_MACHINE\SOFTWARE\BigHand\BHServer_x.x\ServerGuid
g. The Operand and Value will be added to the fields, ensure the operator is equals and click Ok.
h. Select “If the condition is TRUE then Skip this task”.
i. Select “If the condition is FALSE then Execute this task, but skip all remaining tasks in this module” and click OK.
Stop all Master services
a. Create another 5 Manage service tasks and repeat steps a – c for the following services (the order is important to avoid conflicting dependencies):
i. BigHand Gateway service
ii. BigHand External Workflow server service
iii. BigHand Active directory service
iv. BigHand Services host service
v. BigHand Server x.x service

Backup old license file and copy new license file

Click Add and Select Files (Perform operations) from the configuration folder
c. On the settings tab click add and select Delete as the action type
d. In the source path enter C:\Program Files\Common Files\BigHand\BHServer.old (Default location) and click OK.
e. On the settings tab click add and select Rename as the action type
f. In the source path enter C:\Program Files\Common Files\BigHand\BHServer.lic
g. In the Destination path enter C:\Program Files\Common Files\BigHand\BHServer.old and click OK.
h. Ensure Ignore Errors is checked and click OK.
i. Click Add and select Resource (Download) from the provisioning folder
j. On the settings tab click Add and browse to the license file resource
k. Check specify destination folder, in the destination enter C:\Program Files\Common Files\BigHand\ and click OK.
l. Clone both of the File tasks you have just created, open them and change the source and destinations to C:\Program Files\BigHand\BigHand Services\
m. These two file tasks will need conditions so they only run on the master server, click the Conditions tab and click add
n. Select registry setting and add the value from 1f above.
o. Select If true Execute and If false Skip task and click OK

Start services

For this you can use the Service properties (Manage) task in the Configuration folder again, except this time you must select Start service as the new service state. The jobs must run in the following order:
a. BigHand Active directory service
b. BigHand External Workflow server service
c. BigHand gateway service
d. BigHand services host service
e. BigHand Server x.x service (Master site)
f. BigHand Server x.x service (Branch).
Be sure to set a condition on these using the BigHand server GUID as before, that way the job will not try to start services that do not exist.
That’s it, you’re done.
Finally, you could configure a job to check each service and email the results.

29th July 2011

BigHand Digital Dictation and RES Automation Manager – BHF File locations

Whilst this post is targeted at retrieving archived BigHand dictation file locations, it does demonstrate how we can use RES Automation Manager parameters and its Microsoft SQL integration to good effect.

Locating a Dictation File

BigHand holds dictations in a proprietary format with the extension .BHF. This is essentially just a WAV file with minor modifications. Once a user has completed a dictation it will disappear from their view after a pre-determined number of days. If you have a reason to retrieve one of these files once it is removed or if a system corruption means you need to re-import dictations there is no easy way to identify the file, as the files have GUID filenames and can be sitting on any file store server in your BigHand estate. Using a combination of SQL and Automation Manager you can make everyone’s life easier.

Create SQL View

First you will need to create a SQL view on your BigHand SQL instance called Find_Dictation_Location as per the below script:

SELECT a.BH_FirstName, a.BH_LastName, a.BH_UserName, b.BH_Title, CONVERT(varchar(10), b.BH_CreationDate, 103) AS BH_CreationDate,
b.BH_CompletionDate, b.BH_Deleted AS BH_Deleted_Task, b.BH_Destination, b.BH_Description, b.BH_MatterNumber, b.BH_DocumentType,
b.BH_Confidential, b.BH_FileRequired, b.BH_Open, c.BH_FileGuid, c.BH_Location, c.BH_Version, CAST(d.BH_URL AS nvarchar(4000))
+ CAST(SUBSTRING(c.BH_Path, 2, LEN(c.BH_Path)) AS nvarchar(4000)) AS Path, c.BH_Deleted AS BH_Deleted_File
FROM dbo.BH_Users WITH (nolock) a INNER JOIN
dbo.BH_Tasks WITH (nolock) b ON a.BH_UserGuid = b.BH_Author INNER JOIN
dbo.BH_FileLocations WITH (nolock) c ON b.BH_TaskGuid = c.BH_FileGuid INNER JOIN
dbo.BH_Locations WITH (nolock) d ON c.BH_Location = d.BH_Location

Automation Manager SQL Query

Next you need to run a SQL query against that view to retrieve the URL of the file, but the SQL query needs to be edited every time you use it, so let’s create an AM job to do this.
1. Create a Module and Add a SQL Statement (Query) task from the advanced folder
2. On the settings tab add the following SQL query:

select BH_UserName,BH_Title,BH_CreationDate,path,BH_Deleted_File from Find_Dictation_Location
where bh_username like ‘%$[Username]%’ and
BH_Title like ‘%$[Title]%’ and
BH_CreationDate like ‘%$[Date]%’

Note the parameter references in the SQL query ($[Username], $[Title] and $[Date]). These are the fields required to identify the dictation. Obviously these can be changed to any of the fields available in the SQL view.

So that AM can insert the correct variables into the script you will need to create parameters for:
a. Username (Username)
• This will allow a full or part entry of the user who created the dictation
b. Dictation title (Title)
• This will allow a full or part entry of the Dictation title
c. Time and Date (Date)
• This must be the exact creation date; you can set a mask for the parameter on the input tab in the format 00/00/0000.

Once these are created, you will be able to run the query against your SQL instance. It will collect information on the dictations you specified by looking up the relevant GUIDs in the database and create a field entry (Path) that has the URL built up from the separate BH_Locations and BH_FileLocations tables. This will then be presented in the Job results for the query.

View results in Automation Manager Job History

27th July 2011

Using Software Restriction Policies to Block Scripts

When we are implementing RES Workspace Manager POC/Pilot’s on a customer’s site, one of the first things we try and do is create an new AD organisation unit (OU) where our test PC’s or XenApp/RDS servers will be placed. One of the reasons we do this is it allows us to block any existing AD group policies (GPOs) that might impact the POC e.g. startup/shutdown/logon/logoff scripts; especially as these might be the cause of slow logins that we are trying improve using Workspace Manager.

For computer related GPO’s we use “block inheritance” on the new OU. For user related GPO’s we employ the “GPO loopback > replace” technique.

These methods work very well but something I’ve come across on customers sites, they have set the login script in the AD properties for each user and not within any GPO that you are trying to block as you can see in the screen shot below. Generally this is the “old school” method of doing this but its still out there!

This causes us some headaches in our POC/Pilot especially when these users are asked to start testing the POC/Pilot and the first thing that happens is they start complaining that it takes an age to login. Why? Because the script is mapping 24 network drives and 15 printers at logon!!

Therefore, we need to stop this script from running on our POC/Pilot environment. We could do this by simply removing the line from their AD properties but what happens if they still want to use the existing environment that relies on this script to map drives and printers? We need to find another way of doing it…in steps “Microsoft Software Restriction Policies”.

Using Software Restriction Policies will allow us to block these logon scripts without affecting the users ability to use the existing environment and here is how.

Firstly we need to add the Software Restriction Policy to a GPO which will allow it to apply; the easiest way to achieve this would be to add it to the new GPO we have created in the first instance that applies the computer related settings.

Using the Group Policy Management Console (GPMC) edit the GPO and expand the “Computer Configuration/Windows Settings/Security Settings/Software Restriction Policies”

Right click on “Software Restriction Policies” and select “New Software Restriction Policies”.

At which point the you will see some additional settings available.

Right click on “Additional Rules” and select “New Path Rule”.

You now need to tell the policy what path to block scripts running from. Most lightly these scripts will located in the NETLOGON share on your domain controllers (DC); the problem now being which DC will the script run from should you have more than one DC in your environment. Easy we can use the %LOGONSERVER% environment variable that is used to store the logon DC used by the user who is logging on. The Security level should obviously be set to “Disallowed”.

That’s about it!! Now when you logon to the POC/Pilot environment you can be sure any unwanted logon/logoff scripts will be blocked from running.

Nathan

20th July 2011

Change RDS User Logon Modes using RES Automation Manager

[wpdm_file id=6]If you are using Windows 2008 R2 Remote Desktop Services you might have noticed that there are various user logon modes available on the Remote Desktop Session Host; which you can see from the screen shot below:

These are all well and good should you wish to manually change the user logon modes i.e. Allow reconnections but prevent new logins until the server is restarted for say maintenance purposes. But if you are already using RES Automation Manager why not complete this task in a more automated fashion? Well this can be easily achieved by adding the following tasks and module parameter.

Module Tasks:

Module Parameters.

Module Task 1 (Enable Logons):

Add Task > Remote Terminal Server Logons.
Settings > Enable Logons.
Condition Expression > User Logon Mode = 1.
Condition Expression > Computer Function = Terminal Server.
If condition is TRUE then > Execute this task, but skip all remaining tasks in this module.
If condition is FALSE then > Skip this task.

Module Task 2 (Disable Logons) :

Add Task > Remote Terminal Server Logons.
Settings > Disable Logons.
Condition Expression > User Logon Mode = 2.
Condition Expression > Computer Function = Terminal Server.
If condition is TRUE then > Execute this task, but skip all remaining tasks in this module.
If condition is FALSE then > Skip this task.

Module Task 3 (Allow connections) :

Add Task > Registry Settings (Apply).
Settings > Add the following registry value.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server]
“TSServerDrainMode”=dword:00000000.
Condition Expression > User Logon Mode = 3.
Condition Expression > Computer Function = Terminal Server.
If condition is TRUE then > Execute this task, but skip all remaining tasks in this module.
If condition is FALSE then > Skip this task.

Module Task 4 (Allow reconnections, but prevent new logons) :

Add Task > Registry Settings (Apply).
Settings > Add the following registry value.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server]
“TSServerDrainMode”=dword:00000002.
Condition Expression > User Logon Mode = 4.
Condition Expression > Computer Function = Terminal Server.
If condition is TRUE then > Execute this task, but skip all remaining tasks in this module.
If condition is FALSE then > Skip this task.

Module Task 5 (Allow reconnections, but prevent new logons until server is restarted) :

Add Task > Registry Settings (Apply).
Settings > Add the following registry value.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server]
“TSServerDrainMode”=dword:00000003.
Condition Expression > User Logon Mode = 5.
Condition Expression > Computer Function = Terminal Server.
If condition is TRUE then > Execute this task, but skip all remaining tasks in this module.
If condition is FALSE then > Skip this task.

Once you have created the module, when you come to schedule the job its then a simple matter of selecting which logon mode you would like to apply from the job parameters. Of course you can schedule the job on individual, multiple or teams of agents.

To make life even easier I’ve created a handy building block that you can import into your environment.

[wpdm_file id=6]

Any questions just ask.

Enjoy

Nathan

27th May 2011

Add computers to a local group using RES Automation Manager

One of the many built in tasks that are provided in RES Automation Manager is the ablility to add users or groups to a local group on a server or desktop. The task does what it says on the tin but one unknown fact (well to me at least until I tried it) is you can also add computers to a local group too using the same task. A very simple example of this would be when using Remote Desktop Services and the Remote Desktop Connection Broker. In this example each Remote Desktop Session Host that is participating in the farm needs to be added to a local group on the Remote Desktop Connection Broker called “Session Broker Computers”.

To add a computer to the local group you simply need to add a dollar ($) after the computer name in the “User(s) and/or group(s) to add” field as you can see in the screen shot below.

It’s as simple as that!!

Nathan