Posts tagged: Workspace Manager

Moving a WMDB across environments

By Max Ranzau

 

mblsFrom the Desperate Measures Dept. This article is a result of half a days work resurrecting a WM database back from the grave, or more to the point, an old environment in a different domain. There were no buildingblocks, only a full database backup. Ever the optimist, I figured it would be an easy win: A few minutes of restoring, running the /lockedout on the Workspace Manager console, adding a new user to the Technical Manager admin role. Boy, was I wrong… When the full scope of what I had to do dawned on me, I was shouting repeated references to the cocktail above.

Here’s the skinny, I had to move a Workspace Manager database from one environment to another, this meant a new domain too. On the new SQL server, which was going to be the new home for the WM datastore, I restored the db backup and set up a SQL user for it as well, finally installing a WM console and configured it to hit the datastore. Obviously locked out, run pwrtech.exe /lockedout. Then this happens:

Here it is again for the search engines: Access is only permitted from the following domains: Yes, the truth slowly dawns on you: You’re locked out of your own DBMS for real and the only saving grace (/lockedout) meant to pull you out of that s***hole, does absolutely bupkis! I’ll spare you all the futile attempts I went through to solve this and cut straight to the chase to what worked. It’s more than likely not be the quick solve you’re hoping for, but at least it’ll get your WM statastore back in one piece.

Step 1: Identify the former domain FQDN

While I recalled the netbios name of the old environment, I was unsure of the FQDN of the old domain where the WM database used to live. This can be identified like this: Open the WM backup in SQL Mgment studio, open the table tblObjects, look for objects of lngObjectType=64 (click to enlarge)

Step 2: Build a sandbox

In a VM sandbox build, a new clean Domain Controller with the same fqdn as found in step 1. Yes, there’s no use crying about it. It will take the time it takes and it’s the only way as things are as of WM 2015 SR1. This box is temporary and can be tossed out when you’re done with this long sad exercise. OS shouldn’t matter too much as we only need this box to import and cleanse the WM datastore of whatever gunk is preventing the unlock.

Step 2 – Prep the sandbox

  • On top of the sandbox DC, install same or newer version of the DBMS which the database came from or you likely won’t be able to restore your WM database. I’m presuming this to be MSSQL. Be sure to set it up for mixed mode authentication.
  • Restore the WM database into the sandbox DC/SQL.
  • Install the WM Console MSI, preferably the same version as you had in the old environment, however a newer one should [probably] work nicely as well.
  • Run pwrtech.exe /lockedout (copy the path from the console shortcut) and enter your SA credentials and login in the dialog shown above.

And poof! Another roadblock went up. I vaguely recalled from the old environment, that Domain admins were technical managers, but I’d have expected Workspace Manager to be smarter than this:

Sure enough, for the S&Giggles, I tried creating another domain admin and got the same result. Only one way forward then…

 

Step 3 – Create a non-admin user and restore access

  • Create a normal user member of domain users. You can’t make local users here since we’re on a domain controller.
  • Make sure to add this user to print operators as these guys can log on locally, we’ll need this on a server.
  • Log off , log back in with the new normal user
  • start pwrtech.exe /lockedout, fill in the sql credentials to the db and Voilá! Access should be restored.

Step 4 – Prep the sandbox database

Now we have managed to pry open the sandboxed WM database, it’s a matter of getting it prepped, so we can put it back into action in the new target environment. First, let’s take a look at what the administrative roles looks like as of now:

As you can see above, it’s quite obviously pointing to the old LAB domain and the domain admins group, the latter is why logging in with any domain administrator didn’t make any change. Our normal non-admin user has been added as expected as a result of the /lockedout procedure. Next we’re going to add Local Computer as a directory service:

For good measure we’re going to bump the local computers directory service up to first priority:

Note: There’s no point in adding the target domain just yet as it probably can’t be resolved from the sandbox anyway.

  • Once the localcomputer directory service is added, hit Shift+F5 or go to the File|Reload now menu in the console, for the new directory service to be made available elsewhere.
  • Go back to the Technical manager admin role and edit it.
  • Hit Add, Users/Groups and follow the yellowbrick road below as numbered below

  1. Change the dropdown to local computer
  2. Uncheck “Limit to this computer only (NAME)”
  3. Hit search
  4. Pick the normal user you created
  5. Hit ok

If you didn’t dun goof’d, it should look like this:

Step 5 – Make a new backup

Now we’re done playing doctor on the database in the sandbox, let’s back it up and put it over in the target environment. Fire up your SQL Studio, rightclick the RES db and chose backup:

Unless you intentionally aim at overwriting the old backup, be sure to remove it and replace it with a new target backup file:

When the backup is done, go to the backup location C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Backup You may be prompted by this lil’ fella on the right. But not to worry just hit Continue, enter your admin credentials if prompted and everything will be fine.

I noted that for any number of inexplicable reasons the size of the datastore jumped 3-fold. Hopefully this isn’t linear for larger databases!

Step 6 – Restoring the doctored WM database

It’s now time to take the backup of the doctored WM datastore out of the sandbox and put it into the target environment. Once the SQL backup file is copied over to the target SQL box, you’ll probably want to reference the destination database name to the old busted one, so any consoles pointing to it do not have to be reconfigured.

When you delete (make sure it’s the right DB!) put a checkbox in the Close existing connections checkbox.

Now let’s restore the doctored database. Be sure your restore settings look something like this:

Once the database has been restored, make sure you create/edit an SQL user which has DBO on the datastore. In my case, I already had a RESWM user, I just needed to configure the user mappings so the ownership and permission are okay:

If the above fails, it may be due to that an orphaned SQL user without login with the same name already exists in the RESWM datastore, go to security under the WM database and knock it out:

Step 7 – Set up a local user in target environment

We’re almost there now. Go to a computer (in the target domain environment) where you have the RES WM console available, but don’t launch it just yet. Remember we have to add that local user we configured within the WM console in the sandbox previously. If you’re on a domain controller, just create a domain user like you did before, however I’m going to presume you are doing this on a member server: If that’s the case go to Server Manager | Tools menu | Computer Management | System tools | Local users and Groups | Users | rightclick, New user:

Add the ‘normal’ user. Password doesn’t matter. For good measure, add it to the Print operators group again, not that it may be completely necessary but hey, the account is temporary anyway:

Now, hold down shift and rightclick on the Workspace Manager desktop shortcut, and chose Run as a different user on the context menu, entering the name of the computer you are on with credentials of the normal user:

Step 8 – Configure console in the target domain

The context should now launch. Go into User Context, Directory Service and add the current domain:

Note: You won’t be able to neither browse nor test the new domain, as you’re not running the console with a domain user at the moment.

Go back into the Techadm role and delete any references to the LAB domain. We can’t add the target domain just yet as we still are running the console with a local user. Make sure you don’t delete .\normal just yet.

Now, exit the console completely and run the “C:\Program Files (x86)\RES Software\Workspace Manager\pwrtech.exe” /lockedout command. Once again the console executable will prompt you for the SQL credentials, but now since we’ve added the Targetdomain as a directory service and we’ve removed all references to the old LAB doman, we will have success:

Step 9 – Cleanup

We now have full acces again to the databse There’s only a few housekeeping items left to do:

  1. Add any additional necessary users and groups to the TechAdm role
  2. Delete the .\normal user from the TechAdm role
  3. Delete the LocalComputer directory service from User Context
  4. Delete the ‘normal’ local user account
  5. Power down/Save/Revert/Kill the sandbox DC+SQL as you don’t need it anymore.

Conclusion: They said it couldn’t be done and the only way was to restore the buildingblocks that weren’t there. But as you may know, the RESguru never takes no for an answer, neither from a piece of stubborn software, nor incidentally from short managers with girly names! Be that as it may, this was by far the longest workaround I’ve had to come up with in a very long time: I can only wish that RES fixes this snafu so hopefully no one else have to jump through the same hoops as I did to get my WM database back.

 

Setting up a WM console on a jumpbox

By Max Ranzau

 

From the Multiple Hoops dept. The other day I was tasked with setting up a Workspace Manager console on a jumpbox. You know, the typical setup for a client where you VPN into a non-domainmember computer, from where you RDS to the different servers you need to access. The wish is to have the RES WM console running on this box so you don’t have to do Inception-RDS to make a few changes in WM, thus preserving screen real estate. Note: this will of course only work if your jumpbox is allowed to hit the database directly  If the jumpbox is firewalled to the hilt and only allows outbound RDS connections, stop reading right here.

Presuming you’re still with us, you might already have installed the WM console on your jumpbox and connected it to the relay server. When you launch it, you’ll get kicked right back out as the console looks for your local computername\username in the datastore and obviously it’s not there yet, so let’s add it:

The above sounds simple enough, but it appears there’s a few steps to go through, which incidentally left me wondering if there was an easier way to do it. I mean, under applications you can add users manually, but no such luck on Admin roles… (hint hint, nudge nudge dear product management ;)

  1. Assuming you already have WM running on one or more domain-enabled computers, go to one of these. Presuming it’s a Server 2012[R2], launch the Server Manager, goto the Tools menu and Computer Management.
  2. Go to System Tools | Local Users | Users and add a local user. The User name and password must be the same as for the jumpbox local user. This account is temporary and can be nuked at the end of the story.
  3. Now launch the WM console and go to User Context | Directory Services and chose New from the toolbar
  4. In the dialog, chose Local Computer from the Type dropdown and hit Ok. No further changes are necessary. WM now understands that local computer accounts can be used for access control, which also applies to Administrative Roles.
  5. Go to Administration | Administrative Roles | <your security role> | Access Control tab | Add button | Users/group
  6. From the directory services dropdown, chose local computer from the Directory Service dropdown, then search and select your username, which you added in step 2. Be sure the “Limit to this computer only (COMPUTERNAME)”-checkbox is NOT checked.
  7. If you did the above right, your account will be listed as .\username when you return to the previous dialog
  8. Now it’s time to return to your jumpbox and launch the WM console there. Since your username is now in the WM database it will let you. In practice you could stop here, however this would leave the jumpbox username able to launch the WM console from every computer. Let’s just add an ounce more of prevention by locking in the computername too:
  9. On the jumpbox’s WM console, go to Administration | Administrative Roles | <your security role> | Access Control tab
  10. Select your “.\username” and edit it. Repeat step 6, except make sure this to check the “Limit to this computer only (COMPUTERNAME)”-checkbox. When you return to the previous dialog, you’ll note that your account is listed correctly as your jumpboxcomputername\username
  11. As the last loose end to tie up, go back to the domain member computer where you created the temporary local user account and delete it.

 

Updated: DB Cleanup Tool 2.0

By Max Ranzau

 

From the Tools-R-Us Dept. You may recall a while back in February, I reported on a cool utility to address the issue with clearing individual log files in RES Workspace Manager. There’s now a new version 2.0 out from one of our community heroes (=someone who contributes and shares stuff), Patrick van Grinsven in the Netherlands (For the record, Morgan Freeman did not develop it ;). The SQL Database Logging Cleanup Tool has seen a few GUI changes and some other improvements:

  • It is now possible to directly Analyze / Query / Clear the configured logging database if the supplied connection details and logs are valid.
  • It is now possible to Analyze / Query / Clear the logging between dates, or to completely clear the selected log (1)
  • Logging analysis is being sorted descending.
  • Displayed record count added (2)

If you are a RES engineer or admin, this utility should most definitely be in your Bat-utility belt.

For further information and downloads, see the updated article here: doc-icon2

 

Workspace Manager 2012 SR4 Highlights

By Max Ranzau

 

From the Look-Somebody-Had-To-Write-About-This Dept. It’s been a couple of weeks and fairly unannounced the Service Release 4 was released on Nov 11th. I’ve been up to my eyeballs in training so blogging’s been kinda put on the backburner a while. Anyway, here is an overview of selected items I found interesting in the this SR. You can download the full releasenotes at the end of this article and have a closer look yourself.

  • Several performance enhancements in both the console and the agent. Pretty much all the Composition items have received a noticeable performance overhaul and things load faster into the console in general. License processing, Drivemapping and many other things have received a tune-up. Of special notice is the Context | Directory Services, where there now is a new option to “Get group membership using tokens (faster)”. You’ll want to look into this option for multi-domain environments, especially if there’s cross-domain resolving going on.
  • The App-V integration has also seen several overhauls. When you do a Execute Command configuration|action on an App-V managed app, you now have a checkbox to run outside the virtual bubble. In application UserSettings, it’s now also possible to edit what’s being picked up in the Targeted items to capture. Previously WM would grab everything but the kitchen sink for a virtual app. User Restore of App-V items have also been improved however there’s no details as to the specific improvement.
  • A new Lockdown and Behavior option to hide log off in startmenu has been added. Let’s hope this feature isn’t on per default as hide shutdown on workstations is in SR3 (for further details, see Things WM does per default)
  • Registry modification under Composition now has the ability to ignore registry redirection on x64 platforms. This is quite useful if you want to make sure a given registry key goes where it’s supposed to without interference from the OS.
  • Special registry types like OutputReport, ReportStyle, REG_NONE are now supported. I have no idea what these do just yet, but I guess we’ll find out along the way.
  • User Settings now support a direct path for specifying the location of the Personal Settings folder. Check the releasenotes for further info. This is important.
  • Application Icons either pinned or in the startmenu have received yet another overhaul. Hopefully the old blocky icons are now a thing of the past.
  • New registry setting to control if the User Settings caching process is launched (if you’re not using laptops, use this reghack to turn it off). See the updated WM registry guide here. Note, there are several other registry items in this release under the fixes section. I’ll update the registry guide with these asap.
  • There is however one particular new setting which stands out. Look for InterceptManagedApps in the releasenotes. From SR3 Update 8, an interesting new feature has been added to preserve the original command line of managed applications. This is one to watch as it effectively will no more PwrGate.exe shortcuts. Expect a future article about this particular item once I’ve tested it.

In summary this service release is mostly performance enhancements, and the obligatory bugfixes – yet there are several interesting thing to dig into. For more information, go have a look at the releasenotes.

Click here to download:

 

 

What’s up with that other WM service?

By Max Ranzau

 

From the Inquisitive Minds Want to Know dept. Since the release of Workspace Manager 2012 SR3, you may have noticed an extra service has been added, besides the well known RES service (aka “Workspace Manager Agent”), which takes care of synchronizing the local DBcache with the SQL datastore. The other service, is seen in the Services.msc as “RES Workspace Manager PE”, shortnamed RESPESVC:

respesvc

I asked one of our software folks what the purpose of this service is. I was told that RESPESVC plays a role in environment variable injection into intercepted processes & injection of DLL’s in Windows processes for logoff scenario’s. If you are wondering about what the PE part is short for, RESPESVC is RES Privileged Execution Service. In SR4 it will also do Dynamic Privileges, moving that over from the RES service, making the technical architecture of that feature a lot simpler.

I know a few of you likeminded professional tinkerers are wondering; can one do anything interesting with this service? Does it’s credentials need to be reconfigured like with the RES service if you are running SQL authentication? In both cases the honest answer is no. There’s nothing to see here, move along :) This service just needs to be left alone, running with it’s default LocalSystem credentials and the world will be a better place, architecture wise. If this changes, I’ll be sure to let you know.

 

How to roll Workspace Security into a production env

Animated, Gears, boxprod-envFrom the Industrial Might & Logic Dept: Once in a while you may come across the scenario where you need to take control over an existing production environment. While new VDI implementations are sprouting up all over the place, it’s not within everyones budget to put in new plumbing and start building from scratch. Over the years I’ve dealt with several customers who had a beat-up production environment where they were spending their workdays putting out fires (and fighting off Ogres) instead of being anywhere near a proactive state. Proactive is a much abused word, but in my context it simply means being ahead of the curve instead of trying to catch up and never emptying out an ever-growing inbox of trouble. While this may sound like a happy story of rainbows and robot-unicorns to some, I assure you a proactive state of secure workspace management is a reality within your grasp, when you consider using the RES Workspace Manager. Let me share a story on how I did it and give you some useful tips on how you can do it too:

doc-icon2<<< Click here to read the article

Appsense vs. RES round II – Shortcuts!

By Paul Newton

 

h2hThis is the second article in a series (read #1 here), which highlights important differences between how AppSense DesktopNow and RES Workspace Manager 2012 works in practice. This time we will have an in-depth look at how simple or hard it is to create shortcuts for the users in the respective products. While it was suggested in the commentary on the previous article that I had to search for a topic where RES Workspace Manager had the biggest difference to AppSense DesktopNow, I assure you that this was not the case: There are plenty of other examples waiting to be written and we’re just getting started… Click below to read article #2 in this series.

doc-icon2 <<< Click here to read RG058

Appsense vs RES article series

TheEditorEditor’s introduction: I have the pleasure today of welcoming Paul Newton as a guest writer here at RESguru.com! Paul has been in IT for 20 years, with the last 15 years spent in the systems management area. Paul is experienced with AppSense, SCCM, AdminStudio, App-V, Citrix and of course RES Software. He has worked in several large and medium sized enterprises in healthcare, energy, and broadcasting.

In the following article, Paul touches on an interesting subject which is sure to get the attention of the usual suspects ;) Over the years, there’s been a couple of more or less useful comparisons between what the merry folks respectively at AppSense and RES Software do, when it comes to managing the user’s persona/profile/environment/workspace (take your pick). The problem with most comparisons is that they basically end up just being a longwinded list of check boxes of who can do what.

The inherent problem with said approach is this: Whoever “dares” to create such a checkbox comparison sheet between any two or more competing vendors, is likely to have at least two vendors breathing down their neck, as the vendors all essentially want to look their best and have every last darn checkbox filled. For a long time, I’ve been advocating another approach: Presuming Vendor X and Vendor Y’s product can do the same things overall – logically the focus must shift from what CAN be done to HOW IT IS DONE.

As for vendor marketeers, this approach is obviously a lot tougher to deal with, especially if your product interface generally speaking is weak, unstructured or down right complicated to use. For the record, I am not referring to any particular vendor indirectly here – these are plain and objective terms to meter by. Of course it is any vendors prerogative to protest that things aren’t being done right, if there is an easier way that has been overlooked. Either way, this cuts the non-technical muglers out of the discussion, so us folks on the factory floor, the engineers can better figure out what product we want to use and recommend.

This is exactly the approach Paul Newton has taken in this article series, which has been moved to the Techlibrary. Let us hand it over to Paul from here: Click below to read the articles:

doc-icon2<<< Part 1: Drivemappings

doc-icon2<<< Part 2: Desktop shortcuts

 

Workspace Manager SR3 Highlights

By Max Ranzau

 

Update: Since the June 12th, the SR3 9.7.3.0 release has been updated. If you already read this article, cut to the chase below.

From the Yay-New-Toys! Dept. Yesterday we got the long awaited Workspace Manager Service Release 3. Due to yours truly being 6-9 hours behind the rest of the RESverse here in the Bay Area, you won’t hear it first on RESguru, but at least I get dibs on diving into the deep end of the feature pool and perhaps fill in a few blanks that you weren’t aware of. This time we’re in for a treat as there are several new SR3 features to look at. [RANT=ON] It took a little while extra tonight, as the retarded WordPress editor decided to hose my article – twice! And autosave had gone fishin’ as well..#@%&! [RANT=OFF] Anyway, you will find the release notes for download at the end of this article. Here is some of the new enhancements and features in no particular order: Read more »

4 new registry tweaks for Workspace Manager

registry-gFrom the Nuts & Bolts Dept. As the RES WorkspaceManager Updatepack 6 has been finished, we took the time to trawl through the release notes to see what’s been fixed. As always please remember: The RES update packs are not available for direct download and have not been fully regression tested like a Service Release is. You can request these from RES Support if you believe you are affected by one or more of the issues, or if Support recommends you to apply an updatepack. Updatepack 6 contains some rather nifty registry settings, which you can check out here in the one and only WM Registry Guide:

doc-icon2<<< Click here to view the latest registry tweaks in the guide.

Note: if you want to get an earlier heads-up on updates and new articles on this site, consider following @RESguru on Twitter.