Continue reading]]>

VDI-in-a-box graphic

Been looking at replacing our current Terminal Server environment and rethinking our workflow for our end users.  Of course, VDI has come up and I’ve begun to ask whether we should move to some VDI solution or stay with Terminal Services (or Remote Desktop services as Microsoft now calls it).

So, I’ve begun researching.  And researching.  And asking lots of people lots of questions.

The best resources I’ve found so far?  Easy.  Here’s the first:

VDI Smackdown.  This link contains a whitepaper laying out the different VDI solutions, including VDI-in-a-box and Microsoft Server 2012’s solution.  Incredible resource.  Download it now.

Spiceworks.  Their communities are a great source of info.  Lots of IT people with lots of IT wisdom.  If you aren’t a part of the Spiceworks community yet, sign up here.

From what I’ve found, traditional VDI is way too expensive for an organization our size. The rule of thumb is >200 users for traditional VDI to pay off.  So, right now I’m exploring both Server 2012’s enhanced Remote Desktop services, which has a feature for deploying virtual desktops based off a golden image.  The other option I’m looking at is VDI-in-a-box by Citrix.  Dell has a  VDI-in-a-box solution they market called the DVS Simplified appliance, which is basically a R720 server running Windows Server and the Citrix VDI-in-a-box software, but they fully support it.  Given that they own Wyse as well this could be an attractive bundle.

What should I choose?  What should you choose?  Well, that depends on what your goals are.  My goals are the following:

1. Simplified Management for end users
2. A rich end user experience (fast UI reaction, video, desktop sharing, conferencing, viewing CAD drawings)
3. Better management of difficult apps (such as DWG Trueview, Saleslogix desktop manager, GotoMeeting) without jumping through a ton of hoops.
4. Quicker disaster recovery response for our end users.

We haven’t finalized our decision, but I will keep notes on our process and hopefully update this blog with the results.  Stay tuned.

Continue reading]]> I was once tasked with installing Autodesk’s DWG TrueView in a Terminal Server environment.  Needless to say, it didn’t go well.  Autodesk designs everything to run in a stand alone user mode with full admin privileges.  So, to make this work, I found a website that had instructions that worked.  The original site has since removed that posting, but I was fortunate enough to pull it from Google’s cache (thanks, Google!)  I did exactly as this said and all users in my Terminal Server environment were able to use DWG TrueView.  However, those same users also needed full admin privileges on the server.  I have yet to tinker with permissions to get this to work with regular users, as my boss told me to just give ’em admin and then lock them down with Software Restriction Policies and Group Policies, but for those who need a starting point, here it is.

1. Logon as an administrator to the Windows TS
2. Install DWG TrueView 2012 accepting all default setup options
3. After setup is complete, launch the DWG application and make sure it starts successfully without any errors. Then close the application
4. Make sure the following 2 folders were created:
   1. C:\Documents and Settings\%username%\Local Settings\Application Data\Autodesk
      (or on Server 2008 C:\users\%username%\AppData\Local\Autodesk)
      
   2. %APPDATA%\Autodesk
      (Server 2008- C:\users\%username%\AppData\Roaming\Autodesk)
      
5. Create a new folder called, for example, “DWGSHARE” on the local terminal server drive and grant the following NTFS permissions:
   1. Administrators – Full Control
   2. Authenticated Users –  Full control
   3. System – Full Control
      

   (Also create a “Temp” folder below the “DWGSHARE” folder

6. Merge the 2 folders noted in section 4 above to one Autodesk folder ,and copy the New Autodesk folder to the DWGSHARE folder
7. Delete the 2 folders from the user profile and from the redirected application data, if applicable
8. Export the HKEY_CURRENT_USER\Software\Autodesk key using Regedit to a .reg file
9. Edit the exported registry file with notepad , change and replace all values that point to
   C:\Documents and Settings\%username%\Local Settings\Application Data\Autodesk (or on Server 2008 C:\users\%username%\AppData\Local\Autodesk)
   AND %APPDATA%\Autodesk (see 4.B above) to the new “DWGSHARE” folder path

   (I did a replace on “Users\\administrator\\AppData\\Local” with “DWGSHARE” and “Users\\administrator\\AppData\\Roaming” with “DWGSHARE” )

10. Also replace all instances of “C:\\Users\\administrator\\Documents\\” with “C:\\Users\\%username%\\Documents” within the registry file.
11. Import the edited registry file ,start the application and make sure there are no errors, if so this means you are on the right path.
12. Edit again the exported registry file and now replace the path from HKEY_CURRENT_USER\Software\Autodesk to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Autodesk
    (Note – this Registry key is actually the terminal server “install mode” key, each Registry key is automatically pushed to the Current User hive of each user logging on to the terminal server  )
13. Import the file to registry, and make sure the following key  is replaced correctly and identical to exported file:  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Autodesk
14. Logon to the server with a test user and try to launch the DWG application

Just replicated this today and all my terminal server users can use DWG TrueView now.  Did some more testing, and users don’t need to be local admins to run, they just need to be local admins the FIRST time they run it.  So, make them an admin, have them log in and run DWG, then log them out and set them back to normal users.

Continue reading]]> Trying to push out Backup Exec Remote Agent to one of my terminal servers, and I received an error:

Fatal Error 1719: The windows installer service could not be accessed.

Great.  Had this error once before on this server when I was trying to install this legacy application written for Access 2003.  I was able to work around it by not using the Access 2003 engine it was installing, but using the Access 2010 already installed on that server.  Haven’t seen this error since until now.

So, I hit the inter-webs.  Lots of useful advice, unfortunately none of it worked.  For posterity sake, here is what I tried:

1.  Unregistered and re-registered the Windows installer service

msiexec /unregister
msiexed /regserver

This did not work.  Still got the 1719 error.

2. Ran system file checker to fix any broken system files

sfc /scannow

Restarted my server, tried the install, didn’t work.

3. Tried booting into safe mode, and unregistered and re-registered the service again

regsvr32.exe %systemroot%\system32\msi.dll
%systemroot%\syswow64\regsvr32.exe %systemroot%\syswow64\msi.dll

Restarted, still got the 1719 error.  What the heck?

4.  Examined the registry key regarding the MSI Service.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\msiserver

Compared the values here to two other servers I have and found discrepancies.  Hmmm….. this might be it.  So, I saved a copy of the current registry settings, exported the settings from my other terminal server and imported them into my troubled terminal server.  Restarted just for fun, and tried to install my Symantec Backup Agent again.

And, once again, it failed with the same error.

I went to Symantec’s site and searched for 1719 error.  I got 0 results.  Nothing.  I searched and searched and found nothing.  So, I retried the steps above.  I tried re-registering the service in the system32 and the syswow64 folder.  Nothing I did worked.

So, in desperation I went to  Symantec’s site again, browsed through the categories to get to the Backup Exec 2010 product and began going through the troubleshooting options.  Several pages into it guess what I found?  Yep, an article entitled

“When trying to install Backup Exec Remote Agent, Windows reports error “1719 The Windows Installer service could not be accessed“

Gee, thanks for having such a great search engine to find this for me 1/2 hour ago!  The first part of the article was worthless, but the very end had a nice tidbit of info worth trying, so I fired up REGEDIT once again and made the following change:

I changed the WOW64 key in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\msiserver from 1 to 0.

After that, the install worked just fine.  Hurray!  Now, to find an email to Symantec’s webmaster and tell them to fix their worthless search engine.

Continue reading]]> InfoWorld just did a nice little article on the top 10 features in Windows Server 8.  Problem they had was that there were so many improvements it was hard to pick just 10.

Windows 8 Server Manager

Here’s the summary for all you nerds out there:

10: Server Manager- Improved GUI and multiserver management.  Views are search driven, so they can be saved and GUI can be customized.  Plus, manage everything from context menus, all built on Powershell and and WMI.

9: Server Deployment- They added “Scenario based deployment.”  Install on local machine, remote machine, VM, or VHD with deployment to multiple machines automated through Powershell cmdlets and WMI. Plus, move from Server Core to full server by installing a few components.  You can even install the full Server without the GUI.

8: IP address management- Finally, no 3rd party tools needed anymore.  Server 8 introduces a full-featured IP address manager that combines network discovery, static and dynamic address allocation, DNS and DHCP monitoring, and network auditing capabilities all in one place.  It logs actual usage and keeps an audit trail of changes.  Boy, this feature has been LONG overdue!

7: Dynamic Access Control- This isn’t a replacement for standard ACL’s, this is a layer added on top of ACL’s.  What it allows you to do is define access to files based on broad categories tagged in the files themselves.  So, users can tag files, Office can tag files, and Server 8 can tag files.  Then, regardless of where those files are, you can grant or deny access to those files based on the file itself, and not on the directory structure.
To implement, you create claims definitions and file property definitions in Active Directory, and you can use any AD attribute.  The claim travels with the users token.  Get that Access denied error?  No problem.  Users are given a remediation link so they can contact the Help Desk or Sysadmin if they think they need access.

6: Large Hyper-V Clusters-  This is Microsoft’s stab at VMWare.  Hyper-V will support 63 hosts and 4,000 VMs per cluster.  They’ve also added tools like cluster-aware patching, storage resource pools, thin provisioning, storage offload for data transfers, BitLocker encryption for cluster volumes, data deduplication, and live storage migration.  They’ve also added Fibre Channel support to Hyper-V guests.

5: Flexible Live Migration- You can migrate a VM and a VHD to a new server while running.  All that’s needed is your standard Ethernet connection and both machines to belong to the same domain.  No cap on migrations either, just limited by your hardware.

4: Virtual Networking – Microsoft has matched VMWare’s vSwitch feature for feature.  Port ACLs, private VLANs, per-vNIC bandwidth reservations, QoS, metering, OpenFlow support, VN-Tag support, network introspection – and all without extra hardware.

3: Hyper-V Replica- The clunky process of setting up Hyper-V replication has been replaced by a wizard.  Your replica will be no more than 5 minutes behind your live machine, and failover and failback are supported.

2: SMB for server apps- So, you want to share your VHD’s and SQL databases on a commodity file server?  It’s now supported.  You can run your VHD off a SMB2 file share, no specialized storage requirements needed.  This is a big boost for small businesses.  You can create SMB2 clusters as well for inexpensive failover.

1: Simplified Virtual Desktop Infrastructure.  Tired of the pain of Citrix? Server 8 simplifies VDI tremendously.  Remote connections are much lighter weight than R2 (10% of R2’s in Microsoft’s demos.)  Admins have it easier for Terminal Server (Remote Desktop). They have a single admin tool for full deployment, as well as a single unified way to deploy RDSH sessions, pooled (stateless) virtual desktops, and personalized (stateful) virtual desktops.  There are also new virtual hard disks, VHDX files, that store user personalizations, and Microsoft is promising better performance than previous roaming profiles.  I hope so, as user profiles are an issue in my environment.

Well, there ya have it.  Looking forward to more development in this area.

Continue reading]]> So, due to certain pieces of custom software requiring elevated rights, we had to loosen up on user rights in our terminal server environment. But, in an effort to avoid too much damage, we instituted Software Restriction Policies, so users cannot run any executable other than what we specify.

Needless to say, it has been a pain in the rear.

Currently I’m fighting with a remote app that is attempting to launch a Word doc. Problem is, the remote app server has a different version of Office installed, and none of the old Office app paths are in our SRP. Rather than add the numerous dozens of office executables, I’m simply installing the latest version on our app server. The paths for Office 2010 already exist in our SPR, so that should take care of it.

Hopefully as we keep moving on software developers will start being smarter when they design software so I won’t need to go through these gymnastics just to make things work and be secure.