SQL Collation Settings

Took a while to find this information so I thought I'd save it here for future reference.
While rebuilding the Master DB in a SQL Express install to change the collation to match a database to be restored from backup, it may be necessary to translate the name of the collation to match the one displayed during the install, in my case this was for a DB to restore that had SQL_Latin1_General_CP1_CI_AS as the collation.
SQL_Latin1_General_CP1_CI_AS is displayed as "Dictionary order, case-insensitive, for use with 1252 character set" with "Latin1_General" in the SQL 2005 Express installation screens.

Understanding Group Policy Loopback

This is an article I originally wrote on the Experts Exchange site, posted here for my reference.

Group Policy Loopback

A Little on Standard Group policy Processing

Before we look at how loopback processing works it may be beneficial to have a quick refresh on how standard group policy processing works.


Group Policy Objects (GPO) are a collection of configurable policy settings that are organised as a single object and contain Computer Configuration policies which are applied to computers during Startup and User Configuration policies which are applied to users during logon.



All about Scope
The term in scope is used to refer to any GPO that applies to an object (computer account or user account).

Group policies can be applied at four separate points within a domain structure (Local, Site, Domain and Organisational Unit (OU)) and are applied one after the other in precedence order for each step.

So the in scope GPOs for an account consist of all Local policy GPOs, all of the Site GPOs, all of the Domain GPOs and all GPOs linked to each OU in the path of the account object. At each stage a new GPO applies it will overwrite any conflicting settings with its own settings; the final set of policies applied is known as the Resultant Set of Policies (RSoP) and can be viewed on a client device via the RSoP.msc console.

Any GPO that has been denied apply rights or filtered out via WMI Filtering is considered to be Out of scope

Why Loopback
The User Group Policy loopback processing mode option available within the computer configuration node of a Group Policy Object is a useful tool for ensuring certain user settings are applied on specified computers.


Essentially loopback processing changes the standard group policy processing in a way that allows user configuration settings to be applied based on the computers GPO scope during logon. This means that user configuration options can be applied to all users who log on to a specific computer.



When to use Loopback
Common scenarios where this policy is used include public accessible terminals, machines acting as application kiosks, terminal servers and any other environment where the user settings should be determined by the computer account instead of the user account.

Where to Enable Loopback
The setting is found within the Computer Configuration node of a GPO:

Computer Configuration > Administrative Templates > System > Group Policy > User Group Policy loopback processing mode

Replace or Merge
When Enabled you must select which mode loopback processing will operate in; Replace or Merge.


Replace mode will completely discard the user settings that normally apply to any users logging on to a machine applying loopback processing and replace them with the user settings that apply to the computer account instead.

Merge mode will apply the user settings that apply to any users logging on to a machine applying loopback processing as normal and then will apply the user settings that apply to the computer account; in the case of a conflict between the two, the computer account user settings will overwrite the user account user settings.

How Loopback Works
Loopback processing affects the way in which the GetGPOList function operates, normally when a user logs on the GetGPOList function collects a list of all in scope GPOs and arranges them in precedence order for processing.


When loopback processing is enabled in Merge mode the GetGPOList function also collects all in scope GPOs for the computer account and appends them to the list of GPOs collected for the user account, these then run as higher precedence than the users GPOs.


When loopback processing is enabled in Replace mode the GetGPOList function does not collect the users in scope GPOs.

So, without loopback enabled, policy processing looks a little like this:


1. Computer Node policies from all GPOs in scope for the computer account object are applied during start-up (in the normal Local, Site, Domain, OU order).


2. User Node policies from all GPOs in scope for the user account object are applied during logon (in the normal Local, Site, Domain, OU order).

And, with loopback processing enabled (in Merge Mode):


1. Computer Node policies from all GPOs in scope for the computer account object are applied during start-up (in the normal Local, Site, Domain, OU order), the computer flags that loopback processing (Merge Mode) is enabled.


2. User Node policies from all GPOs in scope for the user account object are applied during logon (in the normal Local, Site, Domain, OU order).


3. As the computer is running in loopback (Merge Mode) it then applies all User Node policies from all GPOs in scope for the computer account object during logon (Local, Site, Domain and OU), if any of these settings conflict with what was applied during step 2. Then the computer account setting will take precedence.

And, with loopback processing enabled (in Replace Mode):


1. Computer Node policies from all GPOs in scope for the computer account object are applied during start-up (in the normal Local, Site, Domain, OU order), the computer flags that loopback processing (Replace Mode) is enabled.


2. User Node policies from all GPOs in scope for the user account object are not applied during logon (as the computer is running loopback processing in Replace mode no list of user GPOs has been collected).


3. As the computer is running in loopback (Replace Mode) it then applies all User Node policies from all GPOs in scope for the computer account object during logon (Local, Site, Domain and OU).


But I don't want everyone who logs on to get these Settings
If you want to add an exception to this rule, for example you have used loopback processing to secure a terminal server using replace mode but would like to ensure that the server administrators do not receive the settings; then you can set a security group containing the administrators accounts in the delegation tab of the GPO(s) whilst viewed from the Group Policy Management Console (GPMC) as Deny for the Apply group policy option. This will have to be set for all GPOs that contain user settings you wish to deny that are in scope for the computer account.

In Conclusion
So all you need to do to ensure the User Node setting you want configured in loopback processing applies; is ensure that the User Node setting is in a GPO that is in scope for the computer account object (and that it has precedence over any competing GPOs).

Changing Owner in a BCM Database via CLI

After running in to an issue with a client recently; where following a rebuild of a SBS 2003 single server environment, users could not access their local Outlook 2010 Business Contact Manager databases.

With a lack of any SQL management consoles to change the database owner to the new user accounts created for the new domain I needed to find a command line option.

After much Googling and testing, the following command was the result:

First connect to the BCM instance using SQLCMD
     C:\>sqlcmd -S .\mssmlbiz
Then connect to the database you want to change the owner on
     1> use DBNAME
Type go
     2> go
You should get a confirmation message
     Changed database context to 'DBNAME'.
Now change the owner on the database
     1> sp_changedbowner 'DOMAIN\UserName'
Type go
     2> go
All done, there is no confirmation message

This process has to be used to connect to each BCM database (the use command) and then change the owner for each.

After changing the owner on each database the users could then connect to the BCM database in Outlook 2010.

Took me a while to get this, so seems like a good idea to make a note here...

Hyper-V Home Lab Setup

It's been about a year since I started this blog, and coincidently about a year since I last posted anything...


...so, I find myself with some time, lets try again.


For this post I'm going to detail the steps I've gone through to set up an old work laptop as a Hyper-V test lab; here goes.


Hyper-V Home Lab Setup
For my lab I will be using an IBM T60 laptop as the server, with VT enabled in the BIOS.

This 'server' will be a member of a Workgroup as will the machine I'll be using to perform remote management.

Step 1: Install Hyper-V Server 2008 R2

Available from here, Hyper-V server 2008 R2 is free to use and is a nice and simple install so I'll not go in to any details, the tricky stuff comes later.

Step 2: Configure Hyper-V Server for Remote Management

Tools Used
The following tools are used for this task:
net user – Already installed on the Server Core install of Hyper-V Server 2008 R2
net localgroup– Already installed on the Server Core install of Hyper-V Server 2008 R2
hvremote.wsf – Downloadable script that automates the various tasks required to configure Hyper-V for remote management
cmdkey - Already installed on the Server Core install of Hyper-V Server 2008 R2

Walkthrough

1. On the client download and install the Hyper-V Manager, part of the RSAT SP1 tools for Windows 7.
2. Create user account on the new Hyper-V server using the net user command. In my case I’ll be using the same accountname and password as I’ll be using to log on to the client.  
   Net user accountname password /add
3. Verify via net user, without parameters.
   Net user
4. Make the new account a member of the local Administrators group via net localgroup, this isn't strictly necessary but I'd like to have full admin rights for this account in my lab setup.
   net localgroup Administrators /add accountname
5. Run the hvremote.wsf script on the server.
   cscript hvremote.wsf /add:accountname
6. Reboot the server.
7. On the client, run hvremote.wsf to Allow Anonymous Logon remote DCOM access.
   cscript hvremote.wsf /anondcom:grant
8. On the client, run cmdkey to add credentials, entering the password when prompted.
   cmdkey /add:servername /user:servername\account /pass
9. On the client, run hvremote.wsf to set exceptions in the firewall.
   cscript hvremote.wsf /mmc:enable
10. Edit the local Hosts file on both the Server and the Client, adding entries to facilitate lookup if you don’t have a local DNS infrastructure.
11. On the client, run hvremote.wsf to check for errors.
    cscript hvremote.wsf /show /target:servername
12. On the server, run hvremote.wsf to check for errors.
    cscript hvremote.wsf /show /target:clientname
13. Open up Hyper-V Manager (Administrative Tools).

14. Right Click ‘Hyper-V Manager’ in the left hand TOC, and click Connect to Server.
15. Enter the name of the server in the ‘Another computer’ field, click OK.

16. You should now be connected to your Hyper-V server.
17. All done, time move on to Step 3

Step 3: Configure Virtual Network

In order to connect to the virtual machines from other devices on the network, and to allow the virtual machine to get to the internet, they will need an externally connected virual network configured.

1. Click Virtual Network Manager... in the action pane of the Hyper-V Manager, select New Virtual Network and choose External, then click Add. 
   
2. Name your new virtual network, select the physical adapter to use, then click OK.
   
   
   
3. All done, on to step 4.

Step 4: Install Virtual Operating System

Right, finally it's time to actually create some virtual machines

1. Open up Hyper-V Manager and connect to the Hyper-V server.
2. Right click on the server name then expand New and click on Virtual Machine… The ‘New Virtual Machine Wizard’ will appear, click Next.

3. Name the virtual machine, change the storage location if needed, click Next.

4. Assign memory to the virtual machine, click Next.

5. 
   Select the virtual network you want, click Next.

6. Choose a size for the virtual Hard Drive (remember this is dynamic), click Next.

7. Point to the install media, click Next.

8. Review your settings, click Next.

9. In Hyper-V Manager, Start the new virtual machine then connect to open a console and install the OS. 

Right, now repeat to create virtual machines as required for your lab environment.

I'll try to get slightly better with the formating for the next post.