Search This Blog

Loading...

Friday, September 4, 2015

There was an error connecting to VMware vSphere Update Manager

You might see this error after installing VMware Update Manager plug-in.

There was an error connecting toVMware vSphere Update Manager. Database temporarily unavailable or has network problems.

image

The problem here could be that you installed Update Manager with a remote SQL 2005, 2008 or 2012 database using Windows Authentication and the Update Manager Service is set to log in as a Local System Account.

image

Right click on VMware vSphere Update Manager Service and select Properties:

image

Change Local system Account to your desired service account and password:

image

Click OK to this warning:

image

Restart the service:

image

 Enabling the Update Manager plug-in fails with the error: database unavailable or has network problems (1015223)

Friday, August 28, 2015

SQL Server Reporting Services log database (ReportServer_log.ldf)

I know this is old news, but I have seen the problem on various sites so now it’s time to write a short post about the issue.

You may find that the SQL Server Reporting Services (SSRS) log database ReportServer_log.ldf file is using almost all diskspace. The reason for this is that the Maximum File Size setting
is set to 2TB by default.

By design no Maintenance Plan will shrink the file.

So do you self a favor when installing SCCM and Reporting:

Start SQL Server Management Studio

image

Connect to you SQL Server:

image

Expand Databases. Select the ReportServer database and right click on it. Select Tasks  - ShrinkFiles.

image

Change File type to Log and press OK:

image

Before shrinking here is the size of my ReportServer_Log.ldf

image

And after shrinking:

image

Now Select Properties on the same Database:

image

Go to Options and change Recovery model from Full to Simple:

image

Go to Files and click this icon image  in the Autogrowth / Maxsize column:

image

Now change the Maximum File Size from the default 2.097.152 (2 TB) to something more suitable for your disk size. Here I will change it to  50000 (50 GB)

image

If you change the size settings before shrinking you might see this error

MODIFY FILE failed. Size is greater than MAXSIZE.

So do the shrink first:

image

If you work with custom Reports it would also be a very good idea to create a maintenance plan where you backup and shrink the database regularly.

Thursday, August 20, 2015

VMware vCenter Server SQL problems

When installing vCenter server and you plan to use a external SQL 2012 server, you might see this error even though you already created the required System DSN:

No system DSNs were found on this machine. Please create a DSN for your external database, and click the refresh button.

image

One thing to be aware of is that the driver used must be SQL Server Native Client, not the build in SQL Server or ODBC Driver 11 for SQL Server:

image

You can find the SQL Server Native Client here:

Microsoft® SQL Server® 2012 Feature Pack

Under Install Instructions scroll down to the native client and download (x64):

image

Direct download link as of 09-07-2015) http://go.microsoft.com/fwlink/?LinkID=239648&clcid=0x409

If you by mistake installed Microsoft ODBC Driver 11 for SQL Server uninstall it, you don’t need it:

image

In Programs and Features you only need Microsoft SQL Server 2012 Native Client as shown here:

image

And then when the DSN is available and you click next you might get this error:

The user associated with the DSN has insufficient privileges. Please provide sufficient privileges for the user by granting the user the following permissions:

* VIEW SERVER STATE

* VIEW ANY DEFINITION

image

Let’s do as we are told. On the SQL Management Studio right click on the SQL Server in question and select properties:

image

Select Permissions, select the service account used by the vCenter service and Grant View any definition and View Server state:

image

You specified the service account right before selecting the DSN in the installation:

image

And finally the last problem I have chosen to present here is this error:

The user associated with the DSN has insufficient privileges. Please provide sufficient privileges for the user by granting the user the following permissions:

* SELECT msdb..sysjobs

* SELECT msdb..sysjobsteps

……………..

image

As we probably all can see the is related to msdb access, again in SQL Management Studio, select Security – Logins at the SQL server in Question.

Select the service account used by the vCenter service and select Properties:

image

Select User Mapping. In Users mapped to this login select the msdb database and select db_owner as role membership:

image

Now you should be able to get past the database settings and on to Configure Ports:

image

Friday, August 14, 2015

Rearming Office

When we include Office 2013 in our Build & Capture Task Sequences and use KMS (Key Management Service) we must always remember to rearm Office.

If Office is not rearmed then 25 days after deployment your users will get a notification dialog right after deployment of their new Windows.

This copy of Microsoft Office is not activated
 
This copy of Microsoft Office is designed for corporate or institutional customers. Connect your computer to your corporate network to complete activation. Your system administrator can help.

image

When installing Office we get a 25-day grace period, This is calculated from the day when Office installed in the image and captured to the day we deploy the image. If the difference is more than 25 days, notification will be shown.

From Rearm the Office 2013 installation :

There is a 25-day grace period from the time of installation of Key Management Service (KMS) clients before notifications to activate are displayed to the user. If you want to deploy an image, you must rearm your Office 2013 installation before you capture the image. If you do not rearm, users see notification dialog boxes at the time that the image is deployed, instead of 25 days after deployment. The 25-day grace period gives ample time for a KMS host to be found and activation to succeed. If activation is successful, users do not see notifications to activate.

Rearming does the following important tasks:

  • Resets the grace timer to 30 days.
  • Freezes the grace timer until either an Office application is run, or the ospp.vbs script is run.
  • Resets the client computer ID (CMID). This is important because the KMS host uses the CMID to determine the number of unique clients.

On Windows 7 you can display the Office CMID with this command cscript.exe ospp.vbs /DCMID (path must be Office15 installation folder as shown here):

image

The Windows CMID can be displayed with the command wmic softwarelicensingservice get clientmachineid

image

After SysPrep and capture the very same Office CMID is returned, so SysPrep doesn't change the Office CMID:

image

The Windows CMID has changed as expected:

image

After running the ospprearm.exe, you will see that the OFFICE CMID has changed:

image

On Windows 8 ospp.vbs /dcmid will show the Windows CMID as explained here:

Windows CMID is returned by OSPP.VBS script when running Office 2013 on Windows 8

To find the Office CMID you will have to find eventID 12288 (application event log) and activating request ending with a “5” as shown:

image

OK - now we know why it its important to use ospprearm.exe, let see an example from a SCCM Task Sequence (you can also use a script but remember there are one version for Office x64 and another for Office x86):

image

image

You will notice that both versions are executed, but a condition will make sure that the command is only executed if the file is present on the system:

image

image

You should also note that this issue is the same on Office 2010, just another path to the files:

“%PROGRAMFILES%\Common Files\microsoft shared\OfficeSoftwareProtectionPlatform\OSPPREARM.EXE" and

“%PROGRAMFILES(x86)%\Common Files\microsoft shared\OfficeSoftwareProtectionPlatform\OSPPREARM.EXE"