Search This Blog

Showing posts with label Windows. Show all posts
Showing posts with label Windows. Show all posts

Tuesday, 23 August 2016

Automate the installation of a Windows DataProtector client

A client today wanted to push the DataProtector agent from SCCM / System Center 2012 instead of from Data Protector. It's not that difficult, but I couldn't find the command-line setup documented anywhere.

You will need to run (as an administrator):

  net use r: \\installserver.ifost.org.au\Omniback
  r:
  cd \x8664
  msiexec /i "Data Protector A.09.00.msi" /passive INSTALLATIONTYPE=Client ADDLOCAL=core,da,autodr
  net use /delete r:

Obviously, substitute installserver.ifost.org.au with your install server, and if R: is already allocated, use something else instead.

Then, trigger the following command on your cell manager:

 omnicc -import_host clientname

Replace clientname with the name of the client.

Script this as appropriate (e.g. after the operating system has booted) in order to have an unattended installation.

Friday, 5 August 2016

Data Protector CRS operation cannot be performed in full-screen mode

Today's head-scratcher: after upgrading to 9.07 on a Windows cell manager, the CRS service won't start.

Eventvwr says something even weirder:

The Data Protector CRS service terminated with service-specific error The requested operation cannot be performed in full-screen mode.. 

I was in full screen mode at the time, but it still wouldn't start even when I minimised my RDP session. For my own sanity, I was glad of this.

Trawling through Daniel Braun's http://www.data-protector.org blog, I saw some comments there that it could be related to anti-virus software. Nope, not that either.

The debug.log said something a little bit more believable:

[SmCreateTable] MapViewOfFile(size:17505216) failed, error=[5] Access is denied.

I discovered that I could reliably get that message added that message every time I tried to start the CRS. But what is actually being denied?

So I ran omnisv start -debug 1-500 crm-vexatious.txt

I then had a 160KB file created in C:\programdata\omniback\tmp that began with OB2DBG, ended with crm-vexatious.txt and had CRM in the filename. Good: at least it gets far enough that it can create debug messages.

Scrollling right to the bottom of it, there it was:

Code is:1007  SystemErr: [5] Access is denied
************************   DEFAULT ERROR REPORT   ***************
[Critical] From CRS@cellmgr.ifost.org.au "" Time: 5/8/2016 1:00:33PM
Unable to allocate shared memory: Unknown internal error.

Internally, the function to return a shared memory segement presumably encodes something as 1007; CRS then exits with that code (which is the standard Windows error code for "can't be performed in full-screen mode").

There aren't many reasons for a shared memory allocation to fail. In fact, the only one I can think of that could be relevant here is if the segment already exists. I thought about figuring out what the equivalent to ipcrm is on Windows, gave up and rebooted the box.

And it came up perfectly. Funnily enough, if I had had no idea what I was doing, I would have just bounced the box to see if it would have fixed it, and saved myself a headache and some stress wondering what was going on. Ignorance would have been bliss.

Wednesday, 2 December 2015

My part in the making of WiFi



Between 1994 and 1996 I was working at CSIRO Radiophysics (which turned into Telecommunications and Industrial Physics). Terry Percival was my boss' boss, and Diet Ostry and I shared an office. This story happened just a little bit before Terry, Diet and the two Johns had starting applying the radio signal unsmearing algorithms that CSIRO ended up with patents for which formed part of the WiFi standard.

One day Dr Percival set me (fresh-faced, obnoxious, know-it-all graduate) the challenge of solving the hardest problem in radio communications at the time: how can A and B communicate reliably, if A can't detect C's signal, and C can interfere with B?

My thoughts on the matter was that everyone was mis-stating the problem. It's only going to be a serious problem if you want to broadcast at 2.4 GhZ. If you drop the frequency of the signal down to something so low that even an iron ore mountain is transparent to it, it would be a very strange environment where A & C couldn't communicate.

So therefore, the real problem was that we were trying to do high speed networking. On the contrary, what we should be researching is extremely low-speed networking. How could we have useful and reliable communication at only a few bits per second?

Latency, jitter, high-speed CPUs to perform processing -- all these hard problems go away when you are only dealing in bits per second.

There were three other very good reasons why I thought low-speed networking was the right thing to look at, too: Linux, mining and submarines.

At the time, Linux was just making inroads into our thinking. The business world was dominated by IBM mainframes and (even in 1996) Windows 3.11 crashing was a daily experience for most people's workday.

The prevailing opinion that the team in the signal processing wing of CSIRO Radiophysics developed was that source-available (free-to-modify) software was unstoppable, and in a short time would conquer everything else, particularly Microsoft. After all, if the source was available, the program could never truly become unavailable or die, like proprietary software would. Software distribution bloat was about to go away, because we would all be getting our software in source form and compiling it. The days of elegant software that did exactly what it was supposed to without cruft were just around the corner because of the massive growth in volunteer developers who would tidy up anything and everything.

Which led me to the conclusion that we wouldn't really need high speed networks. The future was going to be everyone having these extremely reliable, high performance desktops (32-bit Linux never crashed; and the difference in this and also in performance was night and day compared to 16-bit Windows 3.11). All the software we would ever want would already be on our local harddisks -- all of it free -- and that there simply wouldn't be enough "stuff" to send over a network to even justify upgrading existing 9.6k modems. (I used to dial in on a 2.4k modem most of the time, myself).

I had been working on a related geophysics project as well. It was deployed on Linux (tying into the future-of-operating-systems theme) and deployed radio transmitters and receivers down boreholes in order to draw conclusions about the kinds of rocks in a region. It seemed like geophysical technologies were going to be a significant part of Australia's research future (at least I got something right!), and the need to deliver communications down into mines (where very low bandwidth would be inevitable) seemed like a worthwhile research direction.

The issues with the Collins class submarines at the time (including: how do we communicate with a submarine deep underwater?) made it seem to me like all the arrows were pointing at low-speed rather than high-speed communication.

I was so convinced that Terry and Diet (and John Deane, who was just down the corridor; and John O'Sullivan whom I think I interacted with a couple of times) were on the wrong track that I ended up quitting CSIRO and joining a private consultancy. This probably diverted me away from academia altogether which is where I otherwise would have gone. With the funding cuts that have hammered Australian research in the last few years, I'm kind of glad about this.

And it was fortunate for everyone else that I quit; I suspect I would have been a pain to work with if I'd stayed, and I'm sure I would have tried (probably unsuccessfully) to push the research in all the wrong directions. I suspect that I might have done such a bad job on the team that they might well have never made any progress to what we now call 802.11b Wi-Fi. On this basis, can I claim that I played a role in the creation of WiFi? By leaving and letting the team hire someone who actually had a clue what they were doing?

I'd like to say that I learn from my mistakes.

Before I got the private consultancy job, I applied for a quant-like role at County Natwest which in the end I turned down (again another lucky save given their history later). I was asked how I thought that County Natwest could make use of the Internet. My answer was that since no-one in their right mind would transfer money over the internet, that all it could be was an information portal.

A decade later (in 2007) I left Google because I was fairly convinced that it was going to fall apart in a few years as Wikipedia became ever more trustworthy that it would become everyone's first point of call for search. It's 2015 now as I search using Google over my home WiFi connection from a proprietary operating system: I have to admit that Bill Gates, Eric Schmidt and Terry Percival were right, and I was wrong.

Based on this, feel free to ignore anything in this blog that you disagree with, since it's almost definitely wrong. But I still think I'm right when I say that my my book of nerd-geek poetry has the best poems about nuclear physics you'll ever see. (And some fun stuff with robots, AI, first contact, and all sorts of other topics. There's even a vampire-at-the-blood-bank.) You really should go and buy it for yourself or your nearest and dearest nerd-geek friends. Here's the Amazon link: When Medusa went on Chatroulette.

Monday, 9 November 2015

Checking StoreOnce stores on Windows

In Data Protector 9.04, I've encountered a problem occasionally where the StoreOnce software store on Windows is completely unresponsive.

The error message that you will see in the session log is unpredictable, but it will often look something like this:

[Major] From: BSM@cellmgr.ifost.org.au "IFOST backup"  Time: 9/11/2015 1:18:44 PM
[61:3003]      Lost connection to B2D gateway named "DataCentrePrimary"
    on host storeonce.ifost.org.au.
    Ipc subsystem reports: "IPC Read Error
    System error: [10054] Connection reset by peer
"

One of the ways of detecting the problem was that the command "StoreOnceSoftware --list_stores" would hang.


I created the following three batch files and scheduled CheckStoreOnceStatus.cmd to run once per hour:

CheckStoreOnceStatus.cmd
start /b CheckStoreOnceStatusController.cmd
start /b CheckStoreOnceStatusChild.cmd
waitfor /t 600 fiveminutes
exit /b
CheckStoreOnceStatusChild.cmd
StoreOnceSoftware --list_stores
WAITFOR /SI StoreOnceOK

CheckStoreOnceStatusController.cmd
WAITFOR /T 30 StoreOnceOK && (
  REM StoreOnce OK
  exit /b
)
REM StoreOnce failure
net stop StoreOnceSoftware
waitfor /t 120 GiveItTime
net start StoreOnceSoftware
exit /b


Actually, I also added a call out to blat to send an email after the net start command.

So, CheckStoreOnceStatus spawns off *Controller, which will wait for 30 seconds for a signal to arrive from *Child as soon as child has been able finish StoreOnceSoftware --list_stores.

Greg Baker is an independent consultant who happens to do a lot of work on HP DataProtector. He is the author of the only published books on HP Data Protector (http://www.ifost.org.au/books/#dp). He works with HP and HP partner companies to solve the hardest big-data problems (especially around backup). See more at IFOST's DataProtector pages at http://www.ifost.org.au/dataprotector

Thursday, 29 October 2015

MS-SQL server not backing up

When Data Protector tries to backup a SQL server, the SQL agent contacts the cell manager to get the details of the integration (e.g. what username to use, whether to use SQL authentication or Windows authentication).

Today I was diagnosing an error message that I never would have expected to see on a MS-SQL server:

Cannot obtain Cell Manager host. Check the /etc/opt/omni/client/cell_server file and permissions of /etc/resolv.conf file.

I'm not exactly sure how I'm supposed to check /etc/resolv.conf on a Windows system. Maybe C:\Windows\system32\drivers\etc\resolv.conf?

Needless to say, in the agent's extreme confusion, it then followed this with:

Cannot initialize OB2BAR Services ([12:1602] Cannot access the Cell Manager system. (inet is not responding)
The Cell Manager host is not reachable or is not up and running
Not exactly that inet is not responding -- it didn't even know what cell manager to connect to.
We probably would have searched for hours trying to find the cause of it, but I proposed upgrading the client to match the cell server version (good practice anyway). The upgrade wouldn't proceed after we hit the following error message:
"Already part of another cell: cellmgr.ifost.org.au ." Note the extra space!
Staring very carefully at the following registry key, I confirmed that indeed, there was a space at the end of the name where it had been manually edited. I removed the space.
HKEY_LOCAL_MACHINE\SOFTWARE\Hewlett-Packard\OpenView\OmniBackII\Site\CellServer

Normally the "already part of another cell" error message means exactly what it says (because it won't match up with your cell manager's name); that there's a short name instead of a FQDN; or some sort of problem like that.

Greg Baker is an independent consultant who happens to do a lot of work on HP DataProtector. He is the author of the only published books on HP Data Protector (http://www.ifost.org.au/books/#dp). He works with HP and HP partner companies to solve the hardest big-data problems (especially around backup). See more at IFOST's DataProtector pages at http://www.ifost.org.au/dataprotector

Friday, 13 June 2014

What a server-less retailer looks like

I've been helping a retail company with a few stores around Sydney. They don't have dedicated IT staff, so every support call is expensive, and having their own servers is very hard.

I got involved because they needed an internal ordering system, which I implemented as a collection of Google Spreadsheets. This was only a temporary fix, as I'm not a great fan of long-term data or business processes sitting in spreadsheets. But one thing led to another and they brought their email over to Google Apps.

To access the spreadsheets and their mail there is a Chromebook in each store. These have been very, very reliable. Months go past without any need for any IT support to fix anything.

They switched over to Saasu for their accounting mainly because they had multiple locations and needed staff to have access to invoicing at the same time. Xero would have been a possibility, but Saasu was (and still is) probably the easier product to use.

Recently they deployed Kounta as a point-of-sale system using ipads together with some Epson POS printers. This was mostly because Kounta supported Saasu; the alternative would have been Vend. In retrospect, Kounta isn't really designed for retailers: their home turf is restaurants and cafes. 
Having the sales report directly into Saasu automatically means that a whole chunk of head-office book-keeping has been eliminated. It's hard to imagine how this could have been done as efficiently if they were still using a on-premises copy of MYOB.
Reporting on what has been sold when has been helpful. For example, they've discovered that some of their frivolous accessory items are actually their best sellers, and they have been able to tweak their pricing as a result.
Internet access is crucial; most of the stores have an ADSL service which can fall back to a 4G service if the ADSL is not working. The original plan was to use Fritz! Boxes to do this, but the 4G modems that were available didn't actually work. It probably would have worked on something more up-market (e.g. a Huawei or Cisco) and might have provided some better diagnostic tools and would let the network be supported by a third party, but they couldn't justify the extra cost.
The procedure now is "in the event of an ADSL failure, turn off the router, and take the 4G modem out of the cupboard". Each store only has three important devices: the chromebook (mentioned before), the ipad (which is the point-of-sale system) and the receipt printer. The receipt printer is not wireless, so during ADSL outages they can't print receipts. Very few of their customers need receipts, so this isn't a big deal. Everything else will pick up on the other router.
Finally, they use Shopify for their internet ordering, again mostly because of its integration with Saasu. They use a combination of Shopify's iphone app and email to notify their staff about the order. This is then manually recorded in their point-of-sale system. Shopify also have a point-of-sale system and this might have been the best option, but Shopify charge a percentage of sales on their low-end plans and this ruled it out. No problems about this for internet sales, but for walk-in retail this seemed a bit greedy.
While there are perhaps more recurring costs (Google Apps, Kounta, Shopify, Saasu and the double internet connection at each store) than a more traditional solution, their savings do appear to more than make up for it. The end result is not enterprise-grade equipment by any means. There has been more cost-cutting and compromises than I am happy with. But the up-front costs are extremely low: lower than it would have been even to put a single good-quality server in at each store, let alone having fail-over server pairs.
Backup being one of my main interests, they only have four data repositories of any importance:
  • Accounting data in Saasu. Xero have an ecosystem of backup providers, Saasu doesn't seem to. However, if Saasu failed for any reason for the long-term, they would have a very reasonable excuse to the tax office for their lack of records. (There would in fact be thousands of businesses affected, so the tax office would have to make some declaration about how to handle it.)
  • Email and files in Google Apps. Spanning have a backup product for this with a remarkable recovery guarantee.
  • Shopify sales. They are duplicated into the point-of-sale system and into Saasu, so if Shopify disappeared there is no financial information lost. There would be customer contact information lost, so perhaps they should use the integration with Mailchimp or feed it into another CRM.
  • Sales records from Kounta. This is a bit of an area of weakness; the only option is manual exports. Vend seems to have better options here.
There are a few Windows desktops in head-office, but as the retail arm is just one part of the larger group, it's fair enough to say that the retailer is essentially server-less. While the transition away from mainframes was momentous in its time ("no tier 1 company can operate without a mainframe") and filled with multi-million dollar replacement projects, the transition away from Windows servers and maintaining internal Active Directory systems seems to be more of a slow slide. It won't be a big occasion: one day we'll wake up to discover that we've turned off the last Windows server and that nobody noticed.