Hammer Blog

Roaming Profile Best Practices

2008-05-28T15:44:02-05:00:00

A lot of us use roaming profiles. There are difficulties associated with this, but once they are mitigated, roaming profiles can be a pretty useful feature. I've written an article which I hope helps you as you deal with potential issues.

http://geekswithblogs.net/HammerTips/archive/2008/05/28/roaming-profile-best-practices.aspx

Regards,

Tom Kretzmer

"Enumerate target servers failed" when attempting to modify or delete maintenance plan

2007-12-14T15:52:46-06:00:00

Originally posted Tuesday, October 23, 2007 10:37 AM.

UPDATE: 12/14/2007

I fixed this error for one instance of my active-active cluster, but I'm still getting the same error on the other instance. I hope this information is useful to someone, as I did eliminate a bunch of possibilities as to the cause, and I did fix it for the one instance.

UPDATE: 11/12/2007

I left my original post below, because it might help someone somewhere.

The actions listed in the old post below help you to enumerate jobs which are not scheduled. The minute you try to have them run automatically, you'll get errors. The errors will be different, but it still won't work.

The problem is that your name is too long. Specifically, <VirtualServerName>\<InstanceName> contains too many characters.

Ok, no problem, just fire up cliconfg and add an alias. Sorry, won't work. Didn't for me anyway.

Answer is to change the virtual server name. Instructions are at http://msdn2.microsoft.com/en-us/library/ms178083.aspx.

Here they are in case that link goes away:

1.) Using Cluster Administrator, change the SQL Network Name to the new name.

2.) Take the network name resource offline. This takes the SQL Server resource and other dependent resources offline as well.

3.) Bring the SQL Server resource back online.

Simple enough, right? One snag I hit after this is that I had Reporting Services already installed, and apparently the name update isn't kind with Reporting Services. I had to do a registry tweak to get it to work.

The error I received when I tried to update the virtual server name appeared thusly:

<error>

Application Error

Event Source: MSSQL$<InstanceName>

Event ID: 19019

[sqsrvres] GetRegKeyAccessMask: Could not get registry access mask for registry key Software\Microsoft\Microsoft SQL Server\MSSQL.3\Cluster (status 0)).

</error>

Turns out there is no \Cluster key for MSSQL.3, because that's the instance for Reporting Services, which is not MSCS-aware.

So I just created a key manually and gave it the "ClusterName"="<ShorterNameOfVirtualServer>"

After this, I updated MSSQL.4 and .5 as well, as these represented the Database Engine and OLAP instance.

These keys will automatically revert to the old virtual server name until you do the same procedure to the other node of the MSCS cluster.

Now you should be able to complete your update. I had to manually start my engine service in Windows Service Manager before I could start the cluster resource the first time from Cluster Administrator.

Connect to the instance now, and you should be able to add scheduled jobs, including Maintenance Plans.

I've spent a lot of hours on this, so I sincerely hope it helps someone.

-Tom Kretzmer

---Older Post---

I just fixed the problem described in this link:

http://www.sqlservercentral.com/Forums/Topic364622-149-1.aspx

Here's the problem:

After an installation of SQL 2005 (Enterprise) 32-bit and updating to Service Pack 2, then creating database maintenance plans, one gets the error: "Enumerate target servers failed for Job 'MaintenancePlan.SubPlan_1'. (Microsoft.SqlServer.Smo)" whenever one tries to modify or delete any maintenance plan or the agent jobs they created.

(Quoted from link at SQL Server Central)

I experienced exactly this error, and spent a few days chasing down a cure. I had already stood up a SharePoint installation previous to discovering the problem, so un-installing and re-installing SQL really wasn't an attractive option. It's fixed now, and unfortunately, I'm not really sure what fixed it. I'll list what I did, and hopefully the next person with this issue will be able to figure out an easier solution.

Initial environment when I noticed the problem was SQL 2005 SP2 on Windows 2003 SP2. Servers configured in an Active-Passive cluster using shared SAN over fibre channel. Cluster uses named instance. All critical updates applied as of 10/11/2007. I then applied the update mentioned at the start of the post (KB934458), to no avail.

It seemed to be to be client related, so I used the SQL Server Surface Area Configuration tool to set the server to a static IP port (1433), using the cluster IP. Then, I used cliconfg to enumerate the instance. No good.

I'm still thinking it's a client issue, and the initial install only installed the client piece (SSMS) on one node of the cluster. I had planned on standing up another instance to make an Active-Active cluster anyway, so I went ahead and installed another instance.

Wouldn't you know it, but the new instance had the same problem again. Well, at least I can try the solution of reinstall SQL without killing MOSS.

So I uninstalled the new instance and reinstalled it a few times, and still had the same issue. I tried it from both nodes, and still didn't work.

Now here is where I'm not sure what fixed it. It could be that I didn't install SP2 on SQL properly on the second instance, which was causing a similar but different error. However, at the same time I found some stuff on Google which suggested something about registration settings. I looked at the registration settings, changed the Connect to Database field to Master and the Network Protocol to TCP/IP, and hit save. I only did that for one of the instance registrations.

Now, suddenly, I can modify maintenance plans and SQL jobs no problem, for both instances. What's strange is that I never touched the first instance, but both nodes can work with both instances without any problems. Also, it continues to work if I set the registration settings back to what they were initially.

I think this may be a bug (sorry, undocumented feature) related to using instances in a clustered environment without any default instance. I saw some posts with people describing some similar behaviors without default instances, which led me to look at SQL registration.

So here is my recommendation. First, force an update with the registration by opening up SSMS and hitting view --> Registered servers. Get to the properties of your instance, make some trivial changes, and hit save. Maybe the problem is it just needs to reset the registration settings. That would be the nicest solution. If that doesn't work, stand up another instance in your cluster (I had additional disks to make an entirely different disk group, but you probably can use the same group). If you're licensed per processor, this won't cost you anything. Apply SP2 and whatever else you need to bring it to the same version as the first instance. See if the problem occurs on both nodes for both instances. Again, if you've fixed it, great. If it's still doesn't work, try to uninstall the new instance and then re-install the instance. Worked for me. If any of this works for you, please add a post saying what is needed - help the next guy. As it is, this info cost me about 2 full days over the last couple weeks.

Good luck!

-Tom Kretzmer

SQL Server 2005 Surface Area Configuration won't load on cluster

2007-12-14T15:48:08-06:00:00

Originally posted Tuesday, October 23, 2007 10:19 AM.

Fairly simple error, but potentially frustrating.

When attempting to use the Surface Area Configuration tool, you get the error,

"You cannot configure surface area of clustered services by connecting to a computer name. Conect to the virtual server to configure clustered services."

I kept figuring it wanted the full path, servername\instancename, or else the name of the cluster.

What it wants is the SQL Network Name as configured in your cluster, no instance name. Hit Change Computer on the initial splash, then set that to the actual SQL Network name.

Good luck!

Service Account "Log on as" repeatedly becoming locked out

2007-12-14T14:45:51-06:00:00

Originally posted Tuesday, October 23, 2007 10:17 AM

I had the issue of configuring a windows service to log on as a service account. This repeatedly caused the account to become locked out. For me, this was happening when installing a Microsoft Cluster Server (MSCS) cluster, but it can happen on any service account.

This will also happen during the installation wizard of MSCS, as well as other installation wizards (MSSQL, etc.) which ask you to enumerate a service account.

In this scenario, you can log onto the server fine yourself interactively. You've checked all the other settings clearly listed in the white paper, but you're still stuck.

Naturally, make sure you're using the right password. That much the white paper will tell you.

This will also happen using the default Windows Server 2003 Service Pack 2 installation if the domain you are using is set up to use the LanManager Compatibility setting of 3, as the default setting is 2.

Change HKLM\SYSTEM\CurrentControlSet\Control\Lsa\lmcompatibilitylevel to match that used by the domain. Restart the computer.

This one cost me 1.25 days.

References:

LanManager Compatibility:

There are many out there - do a search on the Microsoft site using the string, "Control\Lsa\lmcompatibilitylevel". Here's a good overview:

http://support.microsoft.com/kb/239869/en-us

MSCS white paper:

http://technet2.microsoft.com/windowsserver/en/library/5812f3be-8d62-4a27-a865-c6e79a7245c61033.mspx

Search stuff:

Account lockout service account

Windows 2003 MSCS Wizard Installation

Connectivity problems with SQL using NLB

2007-12-14T14:42:43-06:00:00

Originally posted Wednesday, October 24, 2007 4:08 PM

If you are using NLB (Network Load Balancing), you may be forced to use Unicast (as I am). This forces you to create another IP address on another NIC to do operations other than NLB, such as domain access, administration, and connecting to a database.

You may also have the misfortune of being required to set this NIC to use the same subnet.

If you are able to have different subnets, then you need to force all traffic to the database to go out the non-NLB NIC. Do this with Route Add

e.g. route -p ADD <IP of SQL> MASK 255.255.255.255 <gateway of non-NLB NIC>

If you aren't able to do separate subnets, then you still need to make your packets "signed" by the non-NLB NIC. I think I was having a problem caused by SQL not being able to respond to the requesting NIC, because it's in unicast mode serving up NLB. The solution is to force SQL traffic to go out the non-NLB NIC.

Here is one of the errors I was having:

Source: Windows SharePoint Services 3
Event ID: 27745
Login failed for user ''. The user is not associated with a trusted SQL Server connection.
Unable to connect to the database SharePoint_Config on <server>\<instance>. Check the database connection information and make sure that the database server is running.

The fix is pretty much the same as above, only you can't use the gateway of the non-NLB NIC, because it's the same as the NLB NIC (same subnet, remember?)! I tried to use the IF parameter, but the second NIC is designated as 0x10004, which is 65540. The route command didn't like either one of those numbers.

Well, you can just specify the IP address as the gateway, and Route is smart enough to use that NIC as the appropriate interface. So the command is:

route -p ADD <IP of SQL> MASK 255.255.255.255 <IP of non-NLB NIC>

If this ends up not working, I'll just delete the article. =)

Moving articles to blog

2007-12-14T14:40:45-06:00:00

I've noticed that my articles aren't being picked up by the search engines, so must be something funny with the way things are set up. Anyway, I'm moving all my articles to the root of the blog so that they can help someone.

-Tom

Unable to manage form templates

2007-12-07T10:32:32-06:00:00

Just solved a problem, and wanted to document the solution.

Problem:

SharePoint MOSS 2007 Central Administrations site. Select Application Management --> InfoPath Forms Services --> Manage form templates.

This runs the page _admin/ManageFormTemplates.aspx

Response is the ever-helpful SharePoint screen: Error. Unknown Error.

Thanks, guys. How do I turn on custom errors in SharePoint?

And how do I get Manage form templates to work?

Disclaimer:

`No warrantees, express or implied, are granted with this information. Please note that this information is FREE and me being nice enough to give it to you does not mean that you should do anything with it, and that it won't do anything horrible to your systems. Above all, I'm not liable for what you choose to do with it.

As a matter of fact, THIS INFORMATION HAS THE CAPABILITY OF RUINING YOUR INFRASTRUCTURE AND COSTING YOU UNTOLD MAN-HOURS, MONEY, AND DOWNTIME. APPROACH WITH CAUTION.

Your continued reading is evidence of your acceptance of this risk, and your agreement that I have nothing to do with whatever problems you might have.

Solution:

To get useful errors in MOSS is not as easily as .NET, but the answer is out there. Here it is in an easier format.

Find the web.config for the site experiencing the issue (in this, case, the Central Administration site.)

If you're not sure where that is, IIS Manager --> <server> --> Web Sites --> Right-click <Web Site> --> Properties --> Home Directory tab --> Local Path. Copy and paste that string into the address bar of Windows Explorer.

Edit web.config in a text editor (preferably Notepad).

Set <SafeMode ... CallStack="false" ...> to CallStack="true".

Set <customErrors mode="On" /> to mode="Off". (This is the .NET way to turn on stack trace information.) If this is a production system, you should set customErrors mode="RemoteOnly" and troubleshoot from the web server console.

Set <compilation batch="false" debug="false"> to <compilation batch="true" debug="true">

Save your file. (Make sure the editor didn't add a .txt extension or something stupid.)

Now you'll get an error message that actually means something.

In my case, it returned the following error:

Object reference not set to an instance of an object.   at Microsoft.Office.InfoPath.Server.Administration.FormTemplate.SolutionDeploymentFailed()
   at Microsoft.Office.InfoPath.Server.Administration.FormTemplate.get_FormTemplateStatus()
   at Microsoft.Office.InfoPath.Server.ApplicationPages.FormTemplatePropertiesPage.GetStatusString(FormTemplate template)
   at Microsoft.Office.InfoPath.Server.ApplicationPages.ManageFormTemplatesPage.AddTemplateToTable(FormTemplate template, DataTable table, SPWeb web)
   at Microsoft.Office.InfoPath.Server.ApplicationPages.ManageFormTemplatesPage.FillDataTable(DataTable table)
   at Microsoft.Office.InfoPath.Server.ApplicationPages.GridViewPageBase.GridViewDataSourceView.FillDataTable(DataTable table, DataSourceSelectArguments selectArguments)
   at Microsoft.Office.InfoPath.Server.ApplicationPages.GridViewPageBase.GridViewDataSourceView.Select(DataSourceSelectArguments selectArguments)
   at Microsoft.SharePoint.WebControls.AdministrationDataSourceView.ExecuteSelect(DataSourceSelectArguments arguments)
   at System.Web.UI.DataSourceView.Select(DataSourceSelectArguments arguments, DataSourceViewSelectCallback callback)
   at System.Web.UI.WebControls.DataBoundControl.PerformSelect()
   at System.Web.UI.WebControls.BaseDataBoundControl.DataBind()
   at System.Web.UI.WebControls.GridView.DataBind()
   at Microsoft.Office.InfoPath.Server.ApplicationPages.GridViewPageBase.RefreshDataGrid()
   at Microsoft.Office.InfoPath.Server.ApplicationPages.ManageFormTemplatesPage.OnPreRender(EventArgs e)
   at System.Web.UI.Control.PreRenderRecursiveInternal()
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
Troubleshoot issues with Windows SharePoint Services.

I tried a bunch of things, but nothing worked. My partner (development-oriented) and I suspected that a database record in the list of published InfoPath forms had a null where it shouldn't be, but we couldn't figure out how to find the bad record. (Where does SharePoint store the darn thing?)

Well, he wrote up a script which uses imbedded SharePoint code (installed dll's) to get at the forms record, since we never could find the actual record in the database manually.

WARNING!!! This script is capable of deleting all of your installed InfoPath forms, as well as all associated workflows!! Do not run it unless you understand what each line is doing!

Private Function GetFSService() As FormsService
        Dim Farm As SPFarm
        Dim FS As New FormsService
        Farm = SPFarm.Open("Data Source=<DataSource>;Initial Catalog=<SharePoint Config DB>;Integrated Security=True")

        Try
            FS = Farm.Servers.GetValue(Of FormsService)(FormsService.ServiceName)
            For Each frm As FormTemplate In FS.FormTemplates
                frm.FormTemplateStatus.ToString()
                'for each St as Microsoft.SharePoint.SPSite in farm.
                'frm.Delete()
                'Next
            Next
        Catch ex As Exception
            'ERROR
        End Try
    End Function

Ok, have you been warned enough? See that remarked little frm.delete? That tells the system to delete all your stuff. Bad. What my partner did was to unremark the delete command and run the script within VB Studio in debug mode, so he could step through it one line at a time. When it found the first record, he told it to delete the record, then checked the site again. Lucky for us, the record with the null field was the first one in the database. After that was deleted, everything was sunshine, lollipops, and roses again.

So there you go. I doubt you'll hit the same problem as I did; I didn't find any fellow victims on Google. But the methodology for turning off the custom error is darn useful. Thanks to Andrew Connell and Anders Rask.

-Tom Kretzmer

Finally fixed Scheduled Tasks error!

2007-11-12T13:02:32-06:00:00

The problem which has been the bane of my existence for weeks is finally solved. I created this blog to track my answer, which is http://geekswithblogs.net/HammerTips/articles/116261.aspx. Turns out that just because you can generate nice long SQL instance names doesn't mean that you should. I've been banging my head against this wall for weeks. Hope it helps someone somewhere. If it helps you, please say so!

-Tom

Previous Articles Moved

2007-10-23T10:20:47-05:00:00

I realized that my former posts should really be articles, so I moved them over there. Sorry; I'm new to this.

Greetings

2007-10-18T07:39:20-05:00:00

Hello, everyone and anyone.

I'm an IT engineer with 13 years of experience. Like everyone else, I use the Internet to find answers to technical problems. Once in a while, the search engines don't have the answer and I have to find it myself.

I stood up this blog to post answers which may or may not be easy to find elsewhere. Hopefully it adds some value to you. I don't intend to do much talking outside of technical geek speak, so you'll need to go elsewhere to read opinions and other entertaining content. This will just be for technical assistance.

Most work I do is with Microsoft technologies. Lately I'm working with MOSS (Microsoft Office SharePoint Server) 2007, so I would guess most posts will reflect that.

Hope this helps, and welcome. :)

-Tom Kretzmer

MCSE, MCSE+I, MCSE: Security, etc. etc.