Categories
Infrastructure

Blocking the installation of SharePoint 2013…

Recently I came across a thread on SPYAM regarding whether it’s possible to block SharePoint 2013 installations using group policy or through the registry.

Sure enough it’s possible to use the SharePoint 2010 installation blocking technique for SharePoint 2013 with a minor modification. Rather than having the Registry Key be for 14.0, just modify it to be 15.0.

So the key that end up implementing either through Group Policy, Power Shell or Registry key setting is:

HKLMSOFTWAREPoliciesMicrosoftShared ToolsWeb Server Extensions15.0SharePoint

With a DWORD Value of ‘DisableInstall’ with a property value of 1.

Sure you can still install the pre-reqs for 2013, but when you attempt to install the actual SharePoint 2013 binary, this is what you end up with:

SharePoint2013-BlockInstall

Time to pick up that VOIP handset and call the administrator about the GPO that seems to be pushed to my server and why I should be allowed to be moved to another OU that has a different domain linked policy. 🙂

Categories
Administration How To...

No, don’t pull that cord out of the wall…

Are you ever working on a server and you wander away for a few minutes only to come back and find that you’ve been disconnected and your session terminated? Never something fun to work through, especially if you’re installing and configuring a software product.

In most enterprise settings this is something that you’d find in a global policy object enforcing a particular amount of time that you’re able to be Idle prior to being booted from the server. Also there’s another setting regarding the maximum connection timeout – basically how long until your session gets trashed because you decided after you’d been booted for being idle you weren’t going to log back in.

If you’re searching around for these settings, they can be found through your friendly neighborhood group policy object at:

Console RootLocal Computer PolicyComputer ConfigurationAdministrative TemplatesWindows ComponentsRemote Desktop ServicesRemote Desktop SessionSession Time Limits

Specifically you’re looking to see what the settings for the following policies are:

  • Set time limit for disconnected sessions
  • Set time limit for active but idle Remote Desktop Services sessions
  • Set time limit for active Remote Desktop Services sessions
  • Terminate session when time limits are reached

While they may all seem friendly, upon closer examination you’re likely to find that one of these policies is your culprit (more than like the second and third in conjunction with the fourth).

However, oddly enough some folks still use security templates to tighten the policies on their servers.  In which case, there’s also a Registry edit required and a reboot.  Note you should always backup your registry before you make any changes – not for the squeamish of heart.

You’ll find this information along with other helpful information for allowing and disallowing things like the use of the Clipboard (fDisableClip) in the registry branch of:

ComputerHKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindows NTTerminal Services

Note that it’s still called Windows NT and also Terminal Services – I guess that some things never change 🙂

Specifically you’re looking for the following registry strings to modify:

  • MaxDisconnectionTime
  • MaxIdleTime

The decimal values that correspond to these are counted in milliseconds.  For instance, if the MaxDisconnectionTime is set to 300000, this corresponds to 5 minutes (60 seconds/minute x 1000 milliseconds/second x 5 minutes).  If you don’t want to be disconnected or have a max idle time, just set the value to 0 and you’ll be all set.

Happy Implementing!

And if you’re wondering where the title for this blog post came from, check out the Fireside Theater’s “We’re All Bozos On This Bus” radio show. Has something similar where the robot gets unplugged 🙂