Entered issue under Issue Tracker

May 2, 2013 at 9:04 PM
Hi Kendal,

I entered a problem under the Issue Tracker tab on Monday and haven't gotten any response. I'm assuming that's because I didn't post about it here in the Discussions tab. When you have a chance, can you take a look?

Thanks
-A.
Coordinator
May 2, 2013 at 9:29 PM
Oops, I hadn't subscribed to notifications for that page and I had no idea!

The way the code currently works is that when logging is enabled (i.e. logging preference is standard, verbose, or debug) all warnings, errors, information, etc. are written to the log (except for some errors that occur in the RDS-Manager module which I don't control).

When logging is disabled (i.e. logging preference is none, which is the default) then errors are written to the error stream (via Write-Error), warnings to the warning stream (via Write-Warning), verbose messages to the verbose stream (via Write-Verbose), and everything else to the debug stream (via Write-Debug). Errors and Warnings will always show up on the console in this case. Everything else depends on the values for $VerbosePreference and $DebugPreference (which are normally set to SilentlyContinue so you won't see them).

Knowing how it works now, what do you think should be changed with this behavior? Is the change to the default behavior or an enhancement along the lines of supported by a switch parameter?

Kendal
May 3, 2013 at 12:55 PM
Hmm, given that information, then I think a couple things need to be changed/addressed. I was using logging, first standard then debug when it wouldn't produce the Database Engine Assessment spreadsheet.

1) Update the documentation on the logging to reflect the fact that if you use a logging preference, you won't see anything in the stream. Makes sense, but not intuitive, at least not to me.

2) There is definitely something wrong, because the log contained the errors, yet right under the error in the log, this entry occurs:

Instance scan complete (Success: 4; Errors: 0)

when I really did get 4 errors.

Also, I'm finding that the only servers that are failing for me are the windows 2012/sql 2012 combinations. I'm investigating that, but was wondering if anyone else had the same issue with:

Method invocation failed because [Microsoft.SqlServer.Management.Smo.Server] doesn't contain a method named 'EnumClusterMembersState'. (SqlServerDatabaseEngineInformation.psm1 line 6556, char 41)

Let me know if you want any further details.

Thanks
-A.
Coordinator
May 3, 2013 at 2:18 PM
Good feedback!

1 - No problem, I'll make a point to do that. (FWIW also on my to-do list is to write detailed information about each module for anyone who is interested in going beyond the 2 scripts I provided and write their own interesting things. You may have noticed the ?, $, *, !, and + symbols in the log files and wondered what the heck those mean, for example.)

2 - I think it's a semantic issue more than anything. It's a non-fatal error but I log it so you know there was some kind of problem that may need to be addressed. Would it make more sense in the final message to say something like: (Success: 4; Failure: 0) ?

I've had someone else privately tell me they've run into the same problem with EnumClusterMembersState but were running SQL 2012. I check to make sure the target server is SQL 2012, the DB Engine is standalone (i.e. not Azure), and the major version of SMO is 11 (i.e. SMO 2012) but it looks like something else is going on. What OS version are you running the scripts on? Is it 32 bit or 64 bit?

It's definitely part of SMO (see http://msdn.microsoft.com/en-us/library/microsoft.sqlserver.management.smo.server.enumclustermembersstate.aspx) and I haven't been able to reproduce the problem on my (64 bit, RTM) 2012 VMs.

The resolution for the other person was to download and install SMO from http://www.microsoft.com/en-us/download/details.aspx?id=29065.

Kendal
May 7, 2013 at 2:07 PM
I'm running the scripts from my laptop, windows 7, 64-bit. I'll try running them on a server and see what happens. Unfortunately the servers that I'm having an issue with are production servers so I'll have to schedule the update of SMO during our maintenance window. However, I did compare the version of SMO on successful servers to the failing servers and they are the same.

I'll keep you posted.
Coordinator
May 7, 2013 at 2:14 PM
Hi Angela,
SMO only needs to be updated on your laptop (i.e. where the scripts run). Hopefully that makes things a little easier. :-)

Kendal