How to move the SMS_[SITESERVER-FQDN] folder and/or smssqlbkup.log file of the SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] SCCM component and how to fix the latter when it’s broken (SCCM 2012 R2)?

Posted on Updated on

Attention: this blog post has been written based on SCCM 2012 R2, more precisely with SP1. There is a small chance that this article is not completely true for SCCM 2012 R2 without SP1 or even that the content lies quite far from reality in SCCM 2012 non-R2. What is certainly true is this post doesn’t apply for older SCCM versions (2007 and older) for at least a decent amount.

This blog post’s goal is twofold:

  • Describing how to change the location of the SMS_[SITESERVER-FQDN] folder and/or smssqlbkup.log file of the SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] SCCM component. Please read the paragraph “How to change the location of the SMS_[SITESERVER-FQDN] folder and/or the smssqlbkup.log file?” to deep-dive into this one.
  • Describing how the SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] component may be broken, what happens then and how to fix it, even if you didn’t try to change the SMS_[SITESERVER-FQDN] folder and/or the smssqlbkup.log file. See the paragraph “What if the SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] component is broken?” hereunder for that part.

In both cases it may be useful to start with the introduction paragraph “First some background information on SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] component…” below. In the case of fixing a broken component (the 2nd goal of this post) I also think it’s worth reading the part about changing the location of the SMS_[SITESERVER-FQDN] folder and the smssqlbkup.log file, because it contains some in-depth details which may be useful to understand how to fix a broken SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] SCCM component.

If you’re not interested in the how, why, where, when, etc. you can skip everything to the “Summary” paragraph, where you can find the best procedure to change the location of SMS_[SITESERVER-FQDN] folder and the smssqlbkup.log file.

First some background information on SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] component…

On the database server hosting your SCCM 2012 R2 site server’s database there is a Windows service called SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN], with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN (so for example, it’s named “SMS_SITE_SQL_BACKUP_SRV01.DOMAINCOMPANY.COM” if your site server is named “SRV01” and your domain “DOMAINCOMPANY.COM”). This Windows service (see figure 1) is part of an SCCM component (more precisely it’s the actual core of that component) that exists on your database server because SCCM 2012 R2 has installed it there when you designated the database server as the one to be hosting the site server’s database. The Windows service (and so the whole component of course, which carries the same name as the service by the way) backs up the site server’s database and other site server information. It’s controlled by a site maintenance task called “Backup Site Server”.

Figure 1

Besides the registration of that Windows service (SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN]), the component also consists of a set of files of course (figure 2). All these files are within a folder called SMS_[SITESERVER-FQDN], with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN (so for example, it’s named “SMS_ SRV01.DOMAINCOMPANY.COM” if your site server is named “SRV01” and your domain “DOMAINCOMPANY.COM”). Under that folder we have a subfolder named “bin” and another one named “Logs”. The first one contains a subfolder on its own, called “x64”, which contains the binaries used by the component, including the one (smssqlbkup.exe) used by the actual Windows service. One can also spot a config file (srvboot.ini) and a log file (srvboot.log) over there. The other files at that place are all binaries: checkspn.exe, srvboot.exe and vcredist_x64.exe. Now, under the subfolder “Logs” I was talking about a few lines ago, we find 1 file: smssqlbkup.log, the main and most important log file of the component.

Figure 2

The folder and its content is put on a volume chosen by SCCM: the volume with the most free disk space is the winner. If you don’t want the folder to appear on a particular volume, you should place a NO_SMS_ON_DRIVE.SMS file on that volume’s root.

But suppose the folder is placed on the right volume or you just don’t care. What if you change your mind later on? What if that volume gets as full as it can get and you really want to move this folder to another volume (not that this would help a lot, because the folder doesn’t take a lot of disk space, but still…)? Or what if you have SCCM component folders on different volumes and later on you want to group them on the same volume because that’s easier for management?

At the end we can summarize the questions for all those scenarios to 2 simple ones:

  1. How can we determine the location of this folder at install time? This question has just been answered (the NO_SMS_ON_DRIVE.SMS file…), but a few extra words about it is wishful.
  2. How can we change the location of this folder after install time?

If you don’t have multiple volumes on your database server, well, then article isn’t for you and you may skip to the “Greetings and have fun” part at the end of this article! 😉 Otherwise, be invited and read on!

How to change the location of the SMS_[SITESERVER-FQDN] folder and/or the smssqlbkup.log file?

How can we determine the location of this folder/file at install time?

The folder and its content is put on a volume chosen by SCCM: the volume with the most free disk space is the winner. If you don’t want the folder to appear on a particular volume, you should place a NO_SMS_ON_DRIVE.SMS file on that volume’s root.

But… you should be aware of the fact that I’m talking about a clean install here. SCCM tries to fix the component when it detects it’s broken and when it does so, it ignores the NO_SMS_ON_DRIVE.SMS file completely. Read the paragraph “What if the SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] component is broken?” under here to read what exactly happens (summarized: the location for the reinstall is determined by the location of the broken component as known by the site server).

How can we change the location of this folder/file after install time?

It’s not that hard. And at the same it is – a little bit. Continue and you’ll understand.

Windows services are configured in the registry (I’m talking about generic configuration settings right now; other settings can, but don’t have to, be stored somewhere else). One of those settings is the location and name of (so the full path to) the ‘start’ binary for the service (as already mentioned, for the Windows service we’re dealing with here, that’s smssqlbkup.exe). I’m talking about the string named value ImagePath under the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] (the registry key for the Windows service), with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN (see Figure 3). So we should change the drive letter or even some other parts of the path, so the aimed location gets written down there.

Figure 3

This is how we do it (remark: this procedure works, except for 1 file – if you want this to work for everything, don’t stop reading after this procedure):

  1. Stop the Windows service SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN], with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN.
  2. Move the folder SMS_[SITESERVER-FQDN] (with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN) from your current location to the new location. Most changes only involve a volume change. To be able to move the folder, nothing may be in use. That’s why the service had to be stopped first in step 1. Also don’t forget to close your Notepad if you had that component’s log file open to peek into! 😉
  3. Change ImagePath under the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] (with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN) so the new location is reflected here. In most cases only the drive letter has to be changed.
  4. Start the Windows service SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN], with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN.

Voila, c’est ça! Right? Nope… Not really… Well, actually, it depends…

Look, the Windows service now uses the new location, but not for the smssqlbkup.log. The component still looks for that log file in the old location and it even recreates SMS_[SITESERVER-FQDN] (with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN) on your old location and does the same for the subfolder “Logs”, where a new smssqlbkup.log file is created! Now, it could be that you want to separate the log file from the rest and if the old location is what you want for this log file, then you’re done. However, if you don’t want this separation or you do want it, but the old location is not the right place for that log file, then you need to read on.

The string named value TraceFilename under the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Tracing\SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] (with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN) is our hope! There we can change the location of that particular log file (this doesn’t count for the log file srvboot.log though!); see figure 4.

Figure 4

These are the steps:

  1. Stop the Windows service SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN], with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN.
  2. Change TraceFilename under the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Tracing\SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] (with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN), so the new location gets reflected here.
  3. Cleanup if necessary. For example, if the component has autocreated a new folder/file structure for this log file after you have changed the location of the SMS_[SITESERVER-FQDN] folder (with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN) and you didn’t mean that to happen, you might want to cleanup that autocreated structure.
  4. Start the Windows service SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN], with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN.

Note: I’m not 100% sure if the stop and start of the service is always necessary, as I haven’t tested that scenario. If someone wants to check this out a bit further, go ahead and let us all know! One thing I can say is that the log file doesn’t seem to be in use when the service is running (well, that is, at least not the whole time). Besides the needed restart when the file IS in use, it’s also possible that the service only detects the location change when starting, meaning it is possible a restart is ALWAYS needed for the change to be active (it could also be that the service checks periodically, but you want the change to be active sooner than waiting for that next periodic check)! Again, feel free to check this out any further if you want!

So… if we want to change the location of the component’s folder for EVERY subfolder and file, so including the smssqlbkup.log file, then we need the following procedure, replacing the previous ones (attention: please read the following paragraph (“It’s not over yet… How to change the Storage Object at the site server side?”) too, as an even better procedure is provided there):

  1. Stop the Windows service SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN], with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN.
  2. Move the folder SMS_[SITESERVER-FQDN] (with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN) from your current location to the new location. Most changes only involve a volume change. To be able to move the folder, nothing may be in use. That’s why the service had to be stopped first in step 1. Also don’t forget to close your Notepad if you had that component’s log file open to peek into! 😉
  3. Change ImagePath under the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] (with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN) so the new location is reflected here. In most cases only the drive letter has to be changed.
  4. Change TraceFilename under the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Tracing\SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] (with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN), so the new location gets reflected here. Use the same path as in step 3 till SMS_[SITESERVER-FQDN] (not lower of course) if you don’t want to separate this log file from the rest.
  5. Start the Windows service SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN], with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN.

When the paths in step 3 and 4 were not the same till the SMS_[SITESERVER-FQDN] level (not lower of course) before you changed them, that means the log file was (already) separated from the rest. In that case, don’t think SCCM did that automatically; perhaps a colleague of yours changed something in the past…?

It’s not over yet… How to change the Storage Object at the site server side?

You have changed the location of SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] (with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN), but the site server isn’t aware of it yet. Yup, the site server also keeps the location path of site system roles in its configuration. The “Component server” site system role for the database server refers to the location path of the SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] component. By the way, the location of a component is often called a storage object, because it can be considered as an object (as any type of data) which defines the storage (actually names like “storage place” or “storage location” would have been more precise) of something (that “something” is the SCCM component here).

If the path to a site system role is wrong, informational messages (indeed, no errors or warnings!) are spewed (typically once every hour) by the SMS_SITE_SYSTEM_STATUS_SUMMARIZER component informing us that the storage object cannot be accessed (figures 6 and 7). The message’s description contains the storage object, as does the Storage Object column in the Site Status for the Component server site system role for the database server (figure 8).

Figure 5

Figure 6

Figure 7

I had to relocate SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] myself. Before the change the folder was located on the root of the F volume (as shown in figure 6-8), but I changed that to the C volume (as you can see in my previous screenshots except for the last 3 of them). After following the procedure from the previous paragraph you can see on the site server the storage object still refers to the F volume instead of the C volume.

Luckily we can change that too. Just do the following:

  1. Change the string named value “Installation Directory” in the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Components\SMS_SITE_COMPONENT_MANAGER\Multisite Component Servers\[DB-SERVER-FQDN] with [DB-SERVER-FQDN] being the placeholder for the FQDN of the database server hosting the site server’s database (so for example, the last level in the key path is named “SRV02.DOMAINCOMPANY.COM” if your site server’s database server is named “SRV02” and your domain “DOMAINCOMPANY.COM”). Typically it’s only the drive letter that has to be adapted, although that depends on how much of the location has been changed (as said before you can change whole pieces of the path). Figure 9 shows the old value in my case.
  2. Restart the Windows service “SMS_SITE_COMPONENT_MANAGER” (figure 8) on the site server so the change is read in and becomes active.
  3. Restart the SCCM console. Refreshing or changing the node in the console doesn’t update the storage object in the Site Status “view”.

Figure 8

Figure 9

As you can see in the following screenshot (figure 10) the storage object, as shown in the Site Status, is updated.

Figure 10

When SMS_SITE_COMPONENT_MANAGER detects everything is working again, we get a new informational message informing us of that: see figure 11 and 12.

Figure 11

Figure 12

With all the above we can make up the following complete procedure for changing the location of the SMS_[SITESERVER-FQDN] folder and smssqlbkup.log file (note that a slightly better procedure is provided at the end of this paragraph, styled in italic):

  1. Stop the Windows service SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN], with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN.
  2. Move the folder SMS_[SITESERVER-FQDN] (with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN) from your current location to the new location. Most changes only involve a volume change. To be able to move the folder, nothing may be in use. That’s why the service had to be stopped first in step 1. Also don’t forget to close your Notepad if you had that component’s log file open to peek into! 😉
  3. Change ImagePath under the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] (with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN) so the new location is reflected here. In most cases only the drive letter has to be changed.
  4. Change TraceFilename under the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Tracing\SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] (with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN), so the new location gets reflected here. Use the same path as in step 3 till SMS_[SITESERVER-FQDN] (not lower of course) if you don’t want to separate this log file from the rest.
  5. Start the Windows service SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN], with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN.
  6. Change the string named value “Installation Directory” in the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Components\SMS_SITE_COMPONENT_MANAGER\Multisite Component Servers\[DB-SERVER-FQDN] with [DB-SERVER-FQDN] being the placeholder for the FQDN of the database server hosting the site server’s database (so for example, the last level in the key path is named “SRV02.DOMAINCOMPANY.COM” if your site server’s database server is named “SRV02” and your domain “DOMAINCOMPANY.COM”). Typically it’s only the drive letter that has to be adapted, although that depends on how much of the location has been changed (as said before you can change whole pieces of the path). Figure 9 shows the old value in my case.
  7. Restart the Windows service “SMS_SITE_COMPONENT_MANAGER” (figure 8) on the site server so the change is read in and becomes active.
  8. [Optional] Restart the SCCM console. Refreshing or changing the node in the console doesn’t update the storage object in the Site Status “view”.

But… we’ve overlooked one thing. As you can read further down in paragraph “What if the SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] component is broken?”, SMS_SITE_COMPONENT_MANAGER can automatically fix a broken SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] component. If you are in the middle of changing the location it’s not impossible that SMS_SITE_COMPONENT_MANAGER detects the component is broken and reinstalls it. Result: you end up with a confusing situation you don’t want. For example, suppose you’ve just moved the SMS_[SITESERVER-FQDN] folder from the C to the D volume (while the SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] service is temporarily down of course) and just at that moment SMS_SITE_COMPONENT_MANAGER detects this “broken situation”. In this case SMS_SITE_COMPONENT_MANAGER tries a reinstall and creates the old folder again! No, your system is not bewitched, it’s all logical J (more information about all the nitty gritty details in paragraph “What if the SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] component is broken?” herunder) To avoid such timing issues, we can adapt the procedure to the following (finally the ultimate procedure – I’ve put this in italic):

  1. Stop the Windows service “SMS_SITE_COMPONENT_MANAGER” (figure 8) on the site server so the change is read in and becomes active.
  2. Stop the Windows service SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN], with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN.
  3. Move the folder SMS_[SITESERVER-FQDN] (with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN) from your current location to the new location. Most changes only involve a volume change. To be able to move the folder, nothing may be in use. That’s why the service had to be stopped first in step 1. Also don’t forget to close your Notepad if you had that component’s log file open to peek into! 😉
  4. Change ImagePath under the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] (with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN) so the new location is reflected here. In most cases only the drive letter has to be changed.
  5. Change TraceFilename under the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Tracing\SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] (with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN), so the new location gets reflected here. Use the same path as in step 3 till SMS_[SITESERVER-FQDN] (not lower of course) if you don’t want to separate this log file from the rest.
  6. Start the Windows service SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN], with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN.
  7. Change the string named value “Installation Directory” in the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Components\SMS_SITE_COMPONENT_MANAGER\Multisite Component Servers\[DB-SERVER-FQDN] with [DB-SERVER-FQDN] being the placeholder for the FQDN of the database server hosting the site server’s database (so for example, the last level in the key path is named “SRV02.DOMAINCOMPANY.COM” if your site server’s database server is named “SRV02” and your domain “DOMAINCOMPANY.COM”). Typically it’s only the drive letter that has to be adapted, although that depends on how much of the location has been changed (as said before you can change whole pieces of the path). Figure 9 shows the old value in my case.
  8. Start the Windows service “SMS_SITE_COMPONENT_MANAGER” (figure 8) on the site server so the change is read in and becomes active.
  9. [Optional] Restart the SCCM console. Refreshing or changing the node in the console doesn’t update the storage object in the Site Status “view”.

An alternative would be to change as less as possible and let SMS_SITE_COMPONENT_MANAGER fix as much as possible (this of the lazy ones among you). Don’t forget that this deletes all your existing log files though (so typically I do prefer the previous procedure, except when you DO want those log files to be gone anyway). Here is the alternative:

  1. Stop the Windows service “SMS_SITE_COMPONENT_MANAGER” (figure 8) on the site server so the change is read in and becomes active.
  2. Stop the Windows service SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN], with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN.
  3. Delete the folder SMS_[SITESERVER-FQDN] (with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN) from your current location. To be able to delete the folder, nothing may be in use. That’s why the service had to be stopped first in step 1. Also don’t forget to close your Notepad if you had that component’s log file open to peek into! 😉
  4. Change TraceFilename under the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Tracing\SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] (with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN), so the new location gets reflected here. Use the same path as in step 5 till SMS_[SITESERVER-FQDN] (not lower of course) if you don’t want to separate this log file from the rest.
  5. Change the string named value “Installation Directory” in the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Components\SMS_SITE_COMPONENT_MANAGER\Multisite Component Servers\[DB-SERVER-FQDN] with [DB-SERVER-FQDN] being the placeholder for the FQDN of the database server hosting the site server’s database (so for example, the last level in the key path is named “SRV02.DOMAINCOMPANY.COM” if your site server’s database server is named “SRV02” and your domain “DOMAINCOMPANY.COM”). Typically it’s only the drive letter that has to be adapted, although that depends on how much of the location has been changed (as said before you can change whole pieces of the path). Figure 9 shows the old value in my case.
  6. Start the Windows service “SMS_SITE_COMPONENT_MANAGER” (figure 8) on the site server so the change is read in and becomes active. SMS_SITE_COMPONENT_MANAGER will detect SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] isn’t running and can’t be started, so triggering a reinstall according to the new location as just set in “Installation Directory”.
  7. [Optional] Restart the SCCM console. Refreshing or changing the node in the console doesn’t update the storage object in the Site Status “view”.

 

 

How to change other stuff?

Of course you may even change the internal structure of SMS_[SITESERVER-FQDN] (with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN) a little bit when playing with the location settings. It’s all up to you. Typically though, people only want to change the location of the SMS_[SITESERVER-FQDN] folder (most of the time only moving this to the root of another volume and that’s it) and perhaps sometimes also of the smssqlbkup.log file. Other location changes, which adapt the internal structure of the SMS_[SITESERVER-FQDN] folder, are very rare and seldom needed. Be aware that if you change the internal structure you should also change some stuff in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Components\SMS_SITE_COMPONENT_MANAGER\Multisite Component Servers\[DB-SERVER-FQDN]\Components\SMS_SITE_SQL_BACKUP (with [DB-SERVER-FQDN] being the placeholder for the FQDN of the database server of the site server) on the site server.

If you take a look at the registry settings for the Windows service you notice you can also play with its display name (named value DisplayName), its description (which is empty by default – you can add the named value Description to change that), etc. However, all this is outside the scope of this blog post.

And of course you can always learn from the above information to change locations for other SCCM components, isn’t it? 😉

What if the SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] component is broken?

It’s clear that when trying to change the location of the SMS_[SITESERVER-FQDN] folder inappropriately, you can easily break the SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] component on one or more places. So what happens than? This paragraph describes the different “broken scenarios”, what happens at that point and how to fix it. This information is also useful if the component is broken even if you didn’t try to change the location of the SMS_[SITESERVER-FQDN] folder.

Before we really start I would like to talk a little bit about SMS_SITE_COMPONENT_MANAGER. This is a component on the site server that checks if components on site systems are still running smoothly and if not, tries (!) to fix problems automatically (well, it depends actually, more about this later in this post). It possesses a list of site systems, their components and the latter’s locations (as we have already seen in the paragraph “It’s not over yet… How to change the Storage Object at the site server side?”). When you change certain things, like those locations (Storage Objects), SMS_SITE_COMPONENT_MANAGER must be restarted to detect those changes; again, we’ve encountered this already in the forementioned paragraph. The restart is easy: as SMS_SITE_COMPONENT_MANAGER is implemented through a (restartable) Windows service, we can restart that service et voila! Also, SMS_SITE_COMPONENT_MANAGER does its work periodically; if you want to speed things up (for example, fasten the detection and possible fix for a problem), so restarting the service may be helpful.

SCENARIO 1. The SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] component works perfectly on the system it is installed on, but the Storage Object refers to the wrong location according to the site server’s information. This situation is easily achieved when changing the location of the SMS_[SITESERVER-FQDN] folder, but without editing the Storage Object on the site server (we’ve dealt with this situation in the paragraph “It’s not over yet… How to change the Storage Object at the site server side?”). In this scenario the SMS_SITE_COMPONENT_MANAGER detects the SMS_[SITESERVER-FQDN] folder isn’t available (anymore) on the location set for the SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] component. I’ve shown you before this causes SMS_SITE_COMPONENT_MANAGER to spew informational messages to inform you of this issue. Despite SMS_SITE_COMPONENT_MANAGER detecting the issue though, it won’t adapt the Storage Object on the site server, because it also sees the component is running on the database server, so it “decides” not to touch it at all (but it doesn’t update the Storage Object at the site server side either…). With other words, in this scenario the issue doesn’t get fixed automatically. An administrator must correct the problem; see the paragraph “It’s not over yet… How to change the Storage Object at the site server side?” above for details.

SCENARIO 2. Suppose the SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] component works great locally on the database server, but the Storage Object still refers to the wrong location according to the site server’s information (so far the same situation as in scenario 1) and the SMS_[SITESERVER-FQDN] folder still exists at that wrong location. Let me concretize this further. Let’s say we change the location of the component, by copying and pasting the SMS_[SITESERVER-FQDN] folder, while leaving the folder at the old location. If we do that the Storage Object as known by the site server refers to the wrong location, even if a SMS_[SITESERVER-FQDN] folder (with contents!) still can be found over there. In that case SMS_SITE_COMPONENT_MANAGER isn’t smart enough: everything seems to be there at the location it knows, so SMS_SITE_COMPONENT_MANAGER thinks everything is OK – while obviously that’s NOT the case. This scenario is harder to detect. Check if SMS_[SITESERVER-FQDN] doesn’t appear multiple times on the database server; if it does, carefully check if this scenario is the one you’re experiencing and if some of the folders is referred to by the Storage Object at the site server side, although it isn’t the path actually used by the service. You can fix this problem by deleting obsolete/old folders and changing the value of the Storage Object at the site server side to the right location, just as in scenario 1.

Pay attention when you deal with scenario 1: if SMS_SITE_COMPONENT_MANAGER complains about not finding the SMS_[SITESERVER-FQDN] folder, don’t copy or move the right (existing) SMS_[SITESERVER-FQDN] folder to the location referred to by the Storage Object (as known at the site server) or you end up in scenario 2: the status in Site Status is OK again according to SMS_SITE_COMPONENT_MANAGER, but actually it isn’t at all!

SCENARIO 3. The SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] component is broken on the database server itself, more precisely because the component’s registered Windows service (SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN]) is stopped, for example after a bug. SMS_SITE_COMPONENT_MANAGER detects this after a while (or almost immediately after restarting SMS_SITE_COMPONENT_MANAGER) and fixes this by starting the SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] Windows service remotely. Informational message 4702 gets logged (figures 13 and 14). This scenario can actually be a nice one: I’m sure some admins have stopped the service before, noticing that the service automatically starts again (and probably wondering why that happened J)!

Figure 13

Figure 14

SCENARIO 4. This scenario also has a broken SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] component on the database server itself: the SMS_[SITESERVER-FQDN] folder is not present at the location the component’s registered Windows service (SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN]) would expect (as configured in the registry). In this case the service is, of course, not running; it’s not even possible due to the absence of the binaries. This can happen when you stop the service and accidently delete the folder. If the folder and its content is not recoverable, you seem to have a big problem, isn’t it? Well, actually not. SMS_SITE_COMPONENT_MANAGER detects the service is down and tries to start it (~scenario 3), but of course doesn’t succeed. It then tries to reinstall the SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] component, which means the SMS_[SITESERVER-FQDN] folder gets recreated on the location of the Storage Object as known by the site server (even if the volume contains an NO_SMS_ON_DRIVE.SMS file in the volume’s root!) and the service is reconfigured, so the recreated folder is used (the location of smssqlbkup.log is reconfigured too, being the same as the folder’s location, so if there a separation between the folder and this log, it’s “temps passé” now). See figures 15-18, where you can see messages 1087 (the failure of the service’s start), message 1018 (the reinstalling of the component) and message 1019 (the success of the reinstall). In figure 15 you may ignore the error of message 4959 about the SPN: the SPN has already been successfully registered before – I won’t go into detail about this error and why you may ignore it (well, at least in this case), as this is outside the scope of this article.

Figure 15

Figure 16

Figure 17

Figure 18

SCENARIO 5. But what if the Storage Object known by the site server is wrong and the service is stopped? In this case the service gets started (like in scenario 3); after that we get scenario 1 (if the folder at the wrong location doesn’t exist) of scenario 2 (if the folder at the wrong location does exist).

SCENARIO 6. What if the Storage Object known by the site server is wrong, the service is down and the service’s folder doesn’t exist anymore? This triggers a restart attempt of the service, resulting in a failure and followed by a reinstall attempt (which should be successful…) – just like in scenario 4. Important to be aware of is the fact that the recreated folder is located in the location which was and is determined by the Storage Object at the site server side and not by the Windows service’s ImagePath registry named value. This means that if you move the SMS_[SITESERVER-FQDN] folder, doesn’t care about the Storage Object value on the site server, a reinstall can be triggered when the service gets down and SMS_SITE_COMPONENT_MANAGER that; this can be the cause of some very unexpected and confusing situations where suddenly the old SMS_[SITESERVER-FQDN] folder pops up again (except perhaps for the smssqlbkup.log file), as like the devil is involved! J

SCENARIO 7. This scenario also has a broken SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] component on the database server itself: the component’s Windows service (SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN]) isn’t registered anymore, BUT the Service Control Manager (SCM) still knows about the service (which means the service is still listed in the Services console, although with an error). This can happen when you delete its registry key (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN]) and the service isn’t running anymore (just deleting the key doesn’t stop the service as it’s already and still loaded in memory), but the system hasn’t restarted yet since all this happened. SMS_SITE_COMPONENT_MANAGER detects the service is not running and tries to start it, but of course doesn’t succeed (message 1087 is logged to informs us of this). It then tries to reinstall the SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] component (see message 1018). Both messages also showed up in scenario 4 (see the screenshots). Anyway, the reinstall (which is an uninstall followed by a new install) will fail: error message 1091 tells us the uninstall, followed by error message 1020 telling us the reinstall fails; then a new attempt to reinstall will log those 2 messages a second time. See figures 19-21 to have a look at those messages.

Figure 19

Figure 20

Figure 21

Figure 22 shows how Services looks like. The error appearing reads “<Failed to Read Description. Error Code: 2 >” (without the quotes).

Figure 22

It seems scenario 7 is broken a little too much. A new reinstall attempt takes place once every hour alter on (with messages 1018, 1091 and 1020 being logged). I just said “seems”, because we do can fix the problem by restarting the system! Yeej! After doing this we land in scenario 8…

SCENARIO 8. If we have scenario 7, but with the difference that the server has been restarted since the key’s deletion (and thus SCM doesn’t know about the service anymore or otherwise stated the Services console doesn’t mention the service anymore), a reinstall should take place successfully and error message 4959 and informational message 1019 are logged. SCM knows everything it should know about the service, the service is loaded perfectly and Services shows everything peacefully!

SCENARIO 9. Everything works fine, but the location as known at the server side (and as seen in the column Storage Object in Site Status) refers to an unexisting volume. For example, the location stored in the named value “Installation Directory” could say something like “K:\SMS_SRV01.DOMAINCOMPANY.COM” (without the quotes), but the K volume doesn’t exist on the database server. If the service is still running on the database server, we actually experience scenario 1 and nothing corrective happens. If the service isn’t running though, we know the service will be restarted automatically. But if the folder and files behind the service aren’t there (so the location as determined by the named value ImagePath doesn’t exist), that restart will fail (with error message 1087 being logged) and a reinstall will be attempted (informational message with message ID 1018). In this case a reinstall at that unexisting location (in my example, the unexisting K volume) is, of course, impossible! Welcome to scenario 9 J SCCM will try to copy 4 executables (in this order: smssqlbkup.exe, srvboot.exe, checkspn.exe and vcredist_x64.exe, all of them in \bin\x64), followed by 3 DLLs (in this order: srvmsgs.dll, climsgs.dll and provmsgs.dll, all of them to %windir%\smsmgs). Of course, every one of them will fail, causing a message for every file being logged (error message ID 1076 for an executable and informational message ID 1079 for a DLL). Although it fails, note that message 1079 is informational, but this is because the file already exists at the target. In this scenario those 3 DLLs aren’t deleted, as they belong to the “general site system software” (even though SCCM tries to copy them too when fixing SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN]) and that’s not what we’re dealing with in this blog post. Anyway, at the end error message 1020 is logged, informing us that the reinstall has failed. This procedure is repeated hourly. The fix is simple: change the “Installation Directory” named value in the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Components\SMS_SITE_COMPONENT_MANAGER\Multisite Component Servers\[DB-SERVER-FQDN] (with [DB-SERVER-FQDN] being the placeholder for the FQDN of the database server hosting the site server’s database) to a valid path or make sure the unexisting volume gets created on the database server.

SCENARIO 10. This is the same as scenario 9, but the volume is correct, while the path contains unexisting directories. For example, the location stored in the named value “Installation Directory” could say something like “K:\test\SMS_SRV01.DOMAINCOMPANY.COM” (without the quotes) and while the K volume does exist, the folder “test” doesn’t. In this case SCCM creates the missing folder structure when reinstalling. Informational messages 1087, 1018 and 1019 are logged (1087 may be missing if SCCM was already trying to reinstall before, for example because you were residing in scenario 9 and then fixed the volume issue – in that case SCCM will try again to reinstall and won’t try to start the service first, even if you have just adapted “Installation Directory” to a correct value referring to an existing SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] folder.

Let’s summarize all this:

  • SMS_SITE_COMPONENT_MANAGER checks if the SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] Windows service is running.
    • If it is, SMS_SITE_COMPONENT_MANAGER checks if the Storage Object (as known by the site server) still exists.
      • If it is, everything’s fine. Nothing gets or even should be fixed.
      • If not, something’s wrong, but nothing gets fixed automatically. Message 4701 gets logged, typically once every hour.
    • If not, SMS_SITE_COMPONENT_MANAGER tries to start it.
      • If it succeeds, everything’s fine. End of story.
      • If it fails, SMS_SITE_COMPONENT_MANAGER attempts a reinstall based on the Storage Object (as known by the site server).
        • If the service has been unregistered AND the system hasn’t been restarted since yet, it fails – a restart is the solution, so a new reinstall can take place successfully.
        • If the volume which is targeted for the reinstall doesn’t exist, it fails.
        • If something lower level is wrong, it fails. Always think of permissions! Perhaps Process Monitor (available standalone or as part of Sysinternals Suite) can help you out?
        • If folders are missing for the targeted install location (but the volume does exist), they are created and the reinstall succeeds.
        • Otherwise: it succeeds.
    • If it doesn’t know, message 4701 gets logged, typically once every hour. This may be the case when there are network problems, the database server is down or SMS_SITE_COMPONENT_MANAGER has insufficient permissions.

I must say that message 4701, the message that the SMS_SITE_SYSTEM_STATUS_SUMMARIZER logs when SMS_SITE_COMPONENT_MANAGER detects an unexisting Storage Object (as known by the site server), also says the following:

“Possible cause: You accidentally deleted the storage object or took the storage object out of service.

Solution: The components will eventually detect that the storage object no longer exists on the site system and will either recreate it or choose a new storage object.”

My experience doesn’t cover this scenario for message 4701: in scenarios 3-6 I haven’t seen this message logged. Also, I don’t know in which scenario SMS_SITE_COMPONENT_MANAGER would adapt the Storage Object (as known by the site server) automatically (see the piece of text in italic a few lines ago).

Links

Some links about the topic:

Summary

This post wants to inform you of the existence of the component SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] (with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN) and its Windows service of same name and wants to tell you its location (files and folders) can be changed (and how this can be done of course). A special location change is also possible for the main log file, smssqlbkup.log. This way admins can tune where those folders should reside, for whatever reason (administration, disk space,…).

The best procedure to change the location of folder and log file is:

  1. Stop the Windows service “SMS_SITE_COMPONENT_MANAGER” (figure 8) on the site server so the change is read in and becomes active.
  2. Stop the Windows service SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN], with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN.
  3. Move the folder SMS_[SITESERVER-FQDN] (with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN) from your current location to the new location. Most changes only involve a volume change. To be able to move the folder, nothing may be in use. That’s why the service had to be stopped first in step 1. Also don’t forget to close your Notepad if you had that component’s log file open to peek into! 😉
  4. Change ImagePath under the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] (with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN) so the new location is reflected here. In most cases only the drive letter has to be changed.
  5. Change TraceFilename under the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Tracing\SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN] (with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN), so the new location gets reflected here. Use the same path as in step 3 till SMS_[SITESERVER-FQDN] (not lower of course) if you don’t want to separate this log file from the rest.
  6. Start the Windows service SMS_SITE_SQL_BACKUP_[SITESERVER-FQDN], with [SITESERVER-FQDN] being the placeholder for the site server’s FQDN.
  7. Change the string named value “Installation Directory” in the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Components\SMS_SITE_COMPONENT_MANAGER\Multisite Component Servers\[DB-SERVER-FQDN] with [DB-SERVER-FQDN] being the placeholder for the FQDN of the database server hosting the site server’s database (so for example, the last level in the key path is named “SRV02.DOMAINCOMPANY.COM” if your site server’s database server is named “SRV02” and your domain “DOMAINCOMPANY.COM”). Typically it’s only the drive letter that has to be adapted, although that depends on how much of the location has been changed (as said before you can change whole pieces of the path). Figure 9 shows the old value in my case.
  8. Start the Windows service “SMS_SITE_COMPONENT_MANAGER” (figure 8) on the site server so the change is read in and becomes active.
  9. [Optional] Restart the SCCM console. Refreshing or changing the node in the console doesn’t update the storage object in the Site Status “view”.

Last but not least, if the component gets broken, a fix is always possible; the SCCM infrastructure is very robust for component disasters. Thank you, Microsoft!

Greetings and have fun!

Pedro

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s