As I love improving good ideas like the one to create a batch file for restarting the RedDot CMS server without rebooting it, which Fred had the other day here comes my enhancement. I talked to Kim Dezen about enhancing that solution for the RedDot CMS.
The script Fred provided works fine. But you need acces to the RedDot CMS Server via Remote Desktop or even have to sit in front of it. So Kim suggested a nicer solution would be the usage of a user defined job within the RedDot CMS. That saves a lot of time logging in to the system(or walking into the server room, in the other building 500 metres away). It’s quite easy to create a user defined Job inside the RedDot CMS Server Manager. Just a few steps to do that:
(By the way, I like the way how things are solved easily over here in my new company. Great guys!)
What I thought after creating that was, that now everybody is able to use this nice RedDot CMS User defined Job. Well, nice, but sometimes people would be pleased to know who restarted their server during that tender presentation in front of a Fortune 500 CEO, right? Right.
So I tried to have a look at the log file for that job via RedDot CMS > “Server Manager” > “Administer User-Defined Jobs” > “Jobs” > “Restart Server” > And from the “Action Menu” column to the right choose > “View LogFile”.
And voila – now you can see: nothing. Ok, a popup opens and says “The XML page cannot be displayed”. Yeah, I wasn’t ready for that, that was totally unexpectable..
Right, so we have no ordinary logfile which just pops up and we could lean back and look for the suspect.
But I would like to have a logfile and the (only hypothetical, but still) raging project manager would like to have a name!
Sure, you can dig through the server logfiles, but everyone of us who had to that do once in his RedDot CMS developer or administrator career knows, it is not only painful it also takes ages. And a process like restarting the RedDot CMS servers services is not a too small thing to have a own logfile. For example in a running live environment with about 20 to 50 RedDot CMS editors – it could ruin a good amount of work time editors spent on their content. So here is
The code below is a nice combination of the base provided by Fred, a windows command line date-creation script and some help of Paul to thin and optimise the whole thing a little bit(and debug it!).
CLS
@echo off
TITLE Restarting RedDot Services
echo.
FOR /f "tokens=1-4 delims=/-. " %%G IN ('date /t') DO (call :s_fixdate %%G %%H %%I %%J)
goto :s_print_the_date
:s_fixdate
if "%1:~0,1%" GTR "9" shift
FOR /f "skip=1 tokens=2-4 delims=(-)" %%G IN ('echo.^|date') DO (
set %%G=%1&set %%H=%2&set %%I=%3)
goto :eof
:s_print_the_date
SET _log="C:Program FilesRedDotCMSASPPlugInsUserDefinedJobslog%yy%%mm%%dd%_RestartServer_log.txt"
echo ------------------------------------------------------------------------- >> %_log%
echo. >> %_log%
echo running restart script (www.reddotcmsblog.com) >> %_log%
echo %date% - %time% -- Stopping services now >> %_log%
echo y | net stop RdIiceService >> %_log%
:: echo y | net stop RDCMSStarterService >> %_log%
echo y | net stop ObjectService >> %_log%
echo y | net stop DataService >> %_log%
echo y | net stop RDInteropService2 >> %_log%
echo %date% - %time% -- All CMS services stopped. Restarting services now. >> %_log%
echo y | net start RdIiceService >> %_log%
:: echo y | net start RDCMSStarterService >> %_log%
echo y | net start DataService >> %_log%
echo y | net start ObjectService >> %_log%
echo y | net start RDInteropService2 >> %_log%
echo %date% - %time% -- All CMS services restarted. Back to work, busy content bees. >> %_log%
echo ------------------------------------------------------------------------- >> %_log%
ENDLOCAL&SET mm=%mm%&SET dd=%dd%&SET yy=%yy%
I think the RDCMSStarterService doesn’t need to be stopped, as it is stopped by default and set to “autromatic”. I think this service just starts the other ones.
Pretty self explaining, isn’t it? And now we get a nice log result everytime the RedDot CMS User-Defined Job will be executed. That doesn’t give us a name yet. But it tells us in a separate file for each day, the exact server time when the server has been restarted:
------------------------------------------------------------------------------
running restart script (www.reddotcmsblog.com)
Fri 20/03/2009 - 9:56:50.42 -- Stopping services now
The RedDot IICE Service service is stopping.
The RedDot IICE Service service was stopped successfully.
The RedDot Object Service service is stopping.
The RedDot Object Service service was stopped successfully.
The RedDot Data Service service is stopping.
The RedDot Data Service service was stopped successfully.
The RedDot RQL Service service is stopping.
The RedDot RQL Service service was stopped successfully.
Fri 20/03/2009 - 9:57:00.85 -- All CMS services stopped. Restarting services now.
The RedDot IICE Service service is starting.
The RedDot IICE Service service was started successfully.
The RedDot Data Service service is starting.
The RedDot Data Service service was started successfully.
The RedDot Object Service service is starting.
The RedDot Object Service service was started successfully.
The RedDot RQL Service service is starting.
The RedDot RQL Service service was started successfully.
Fri 20/03/2009 - 9:57:10.01 -- All CMS services restarted. Back to work, busy content bees.
------------------------------------------------------------------------------
That doesn’t give us a name yet, but the exact server time of our RedDot CMS engine to look up in the RedDot log and then the project manager can freak out – everybodie is happy. End of story.
To DOWNLOAD the file. Click here and after that it would be nice, if you would DONATE here.
What about the PageBuilder and XMLServer COM+ components?
From time to time it is necessary to restart one or both of these as well.
(e.g. when you “Clear Page Cache” from the project node, this actually clears the cache in memory in the running PageBuilder COM+ component, as well as in the file system)
For some changes made to RDServer.ini, main.config, or other restarting one of these could be necessary.
For changes made to the RedDotCMSServiceProcess.exe.config, restarting the RedDot Object service will always suffice as restarting this will end and start a new RedDotCMSServiceProcess.exe (which will put changes made to the .exe.config into effect)