SQL Management Express and Microsoft##SSEE

Download and install Microsoft SQL Server Management Studio Express

Download and install Microsoft SQL Server 2005 Express Edition Toolkit

Configure the built-in SQL instance for remote management by SQL Server Management Studio Express

  1. Open the “SQL server Configuration Manager”
  2. Right-click the line “Protocols for MICROSOFT##SSEE” and choose “Properties”
  3. Set “hide instance” field is set to “no” instead
  4. Under protocols, enable TCP/IP and Named Pipes
  5. Restart the microsoft##ssee service

I found the above steps here.

Access the SQL instance using SQL Server Management Studio Express

  1. Start SQL Server Management Studio Express
  2. Connect to this instance: \.pipeMSSQL$MICROSOFT##SSEEsqlquery
  3. You may need to check Windows Authentication

I found the instance name here.

Now that you have access to the instance you may perform regular tasks to it, such as backing it up, detaching it and so on.

Complicated Printing

Why does printing need to be so complicated? Admittedly a portion of the problem falls on us running our own domain. At times it can be irritating, like now, and at times it can be a lifesaver. So this is our situation, we run an independent ActiveDirectory domain that has an external trust with the main campus domain. Our domain is a resource domain in the NT4.0 version of the term. We have almost no actual user accounts in our domain, but all of the computers we manage exist in our domain.

The University recently rolled out a new Multi-Function Print Device contract. Central IT will maintain control over the printers and we’re responsible for the consumables. Printing has been problematic for us, but we managed to get a good working solution going. With these new printers, we decided to leave them on Central’s print server and then push them via Group Policy.

At first blush that appeared to work perfectly fine. All of the computers in our office were able to connect and see the printer, the one thing worth noting is that all of our computers are Windows 7. When I fired up my Windows XP computer, the printer showed up, but nothing else. Attempting to print, access properties, or open the queue resulted in an error.

We started working on this problem, originally thinking maybe it was a cross-forest trust issue. That was quickly tossed as the Windows 7 computers could connect to the printer, and people who had the printer manually added could print. Adding the user to the administrators group sort of worked, but as we don’t really roll that direction with our users we decided against that route as well. We started working with tweaking group policies for printing, defining approved servers in both Package Point and print (doc), as well as Point and Print Restrictions.

It turns out that we were going about it backwards, the Point and Print Restrictions policy was the correct policy for Windows XP. But instead of enabling the policy and defining a list of print servers, the key was to DISABLE the policy. Part way down the above KB article is the following bullet:

“If you set the policy to Disabled, users can use the Point and Print functionality to select any shared printer they have access to.”

For clarification there was a thread from 2004 on tomshardware.com, where a Microsoft tech added the following:

“When the policy setting is enabled, the client can be restricted to only point and print to a server within its own forest, and/or to a list of explicitly trusted servers.

When the policy setting is not-configured, it defaults to allowing point and print only within the client’s forest.

When the policy setting is disabled, client machines can point and print to any server.”

To test we created a policy with nothing in it, aside from disabling Point and Print. We booted up a fresh install of Windows XP and a user with no administrative access and were able to connect to the printer and send a test page.


I created a simple script that I placed on our public share. The script’s sole purpose in life is to map a single printer, this printer is provided via the parameter box in Group Policy. It connects to a print server that you set inside the script, maps the printer share that you provide as a parameter, and then either makes it the default printer or doesn’t.

Here is the link to the source of the script.

Delegation of OU and GPO’s

Recently A department within the School wanted to leverage the capabilities that we currently provide many other departments. They currently run their own domain, and they needed the same amount of control if they were to migrate over to our domain. Of course the “easy” button here is the Delegation of Control Wizard. This gives you the ability to grant a user in your domain or another trusted domain the ability to administer all or a portion of the objects within an OU.

Now, while your newly created OU Admin can create user accounts, computer accounts, organizational units and groups, she does not get the ability to create Group Policies. If you gave the account Full Control you can check permissions on the OU you will see that Create and Delete GroupPolicyContainer objects are checked Allowed. When your admin attempts to create a group policy or run the modeling wizard it will fail with “Access is Denied.”

This is because while she has Full Control at the OU level, her account needs to be added to the Group Policy Objects container in the GPMC interface. Once you have added the account there, your admin will now be able to create/edit/delete gpo’s.