Wednesday, May 24, 2017

Skull Canyon NUC UEFI install

I was trying to do a clean install of Windows 10 on the Skull Canyon Intel NUC (NUC6i7KYK).

At first, I thought there was something goofy with the USB stick that I was using as the UEFI boot (F10) would see the stick but when I selected it as a boot device, it would just return me to the boot menu and apparently do nothing.  Tried different USB stick; tried different ways of building the USB stick; tried different USB ports; tried to update the BIOS (from 0041 to 0046).  No joy.

What ended up working was enabling the UEFI shell from the BIOS.  After booting into the UEFI shell, I could then specify the USB stick and then manually run \efi\boot\bootx64.efi.  Install worked fine after that.

Thursday, November 27, 2014

Basis Peak vs. Carbon Steel

I just upgraded from the Basis Carbon Steel to the new Peak.  The data was preserved in the migration and all I needed to do was install a new app on my iPhone and log in again.

Some random thoughts:

  • The screen is larger but it is less thick. As such it feels smaller in some sense.
  • The new charger doesn't require the unit to be slid in; you can just drop it on there. However, it seems to have the same problem that if you aren't paying attention, you can put it on the  'wrong way' and even though it is seated snugly, it doesn't appear to charge.
  • A 'power brick' for the USB adapter wasn't provided. I don't mind since I have the Anker 40W 5-port USB charger.
  • The gestures you use to do things (turn on/off backlight) isn't obvious and the documentation is hidden at  I would have thought there would be a quick cheat-sheet in the packaging but I don't remember seeing it.
  • The band feels more comfortable. I don't know why.
  • Firmware updates can be done from the phone now so it doesn't look like you need to periodically attach it to a computer.
  • Sync'ing is now continuous so you don't need to remember to manually sync (or forget and fill the memory of the unit).
  • The constant connection to the iPhone 5 doesn't seem to be a bad battery drain
From a marketing perspective for current customers, they offered a $30 credit after I had already pre-ordered and received the Peak from Amazon.  That was really bad timing and what is disappointing is that they aren't offering that credit towards something like a second charger. 

At this point, none of the advanced functionality (seeing texts on the screen, stop watch, etc.) is available which is a little disappointing. Hopefully, it won't be too long before these updates come out.

Sunday, July 06, 2014

ServiceNow: gs.dateDiff() returns the wrong results (sorta)

Do you see what is wrong with this code?
var date1 = new GlideDateTime(); 
var date2 = new GlideDateTime(); 
var date3 = new GlideDateTime();
date1.setDisplayValueInternal('2011-08-26 17:12:28'); 
date2.setDisplayValueInternal('2011-08-30 12:33:10'); 
date3.setDisplayValueInternal('2011-08-30 12:43:10'); 
gs.print(gs.dateDiff(date1, date2, true)); 
gs.print(gs.dateDiff(date1, date3, true));
If you run the code, you'll see that gs.dateDiff() returns the same value for the difference between date1/date2 and date1/date3 even though there is a 10 minute difference.  Why is it rounding to the full number of days?  

Well, it turns out that the default string conversion is not what gs.dateDiff() is expecting.  Instead, it is expecting the date/time string in the user's display format.  

(so if your default date / timeformat matches the internal, then you'd actually get the correct results and wonder what I'm complaining about.) 

Instead of just failing, gs.dateDiff() seems to do the math where it can (e.g. the difference in days). This seems a poor choice in that you are giving the impression of valid results when the results are not accurate.

What you need to do to make sure you get the correct results is the following:

gs.print(gs.dateDiff(date1.getDisplayValue(), date2.getDisplayValue(), true));
gs.print(gs.dateDiff(date1.getDisplayValue(), date3.getDisplayValue(), true));
getDisplayValue() converts the internal date format to the one expected in the execution context.

Saturday, July 05, 2014

Servicenow: obvious in hindsight

Another 'duh' moment.

The use of gs.addInfoMessage() will not work with business rules set as 'async'. If you want the message, you need to wait and use 'after'.

Yeah, this is obvious in hindsight as the execution of the BR may not immediately occur so you can't get the message to appear on the next loaded page. 

Sunday, June 29, 2014

ServiceNow Survey Wizards: Redirect at the end of the survey

You would think it would be really simple to specify where you want to go when you are done with a Survey created by a Survey Wizard.  You'd be mostly right.

If you select the Survey Wizard in question, you'll notice that there is nothing on the page, because, well, that'd be too easy.  You'll need to Personalize the form and add 'Redirect' to the form. After that, it is a 40 character (beware long urls) string field that you can put in a url that you will be redirected to at the end of the survey.

Do not waste your time by trying to use a redirect panel. They don't seem to work. If you do go down the redirect panel path and wonder why they aren't showing up on the main survey wizard panel under 'survey panels', that's because you need to personalize the form and add 'redirect panels' as its own tab. 

What would have been nicer is if everything were hidden. That way, you'd know to go look.  Rolling 1d4 to see if the field should be hidden seems bordering on cruel and inhumane.

If you are on Eureka, it looks like there is a newer survey mechanism so all this may be moot.

Tuesday, June 24, 2014

[LDAP: error code 12 - Unavailable Critical Extension] in ServiceNow Eureka

The new Eureka release for ServiceNow supports persistent search for non Active Directory servers. Woo!

However, you enable the listener and you get the error: "[LDAP: error code 12 - Unavailable Critical Extension]"  Boo!

Turns out that when you configured your LDAP server ages ago, you may have set the 'Vendor' field to be 'Active Directory' because, hey, that was the default or you wanted to see if changing the vendor field did anything.  Since it didn't, you may have forgotten to change it back.  It doesn't help that the server configuration page doesn't show this field (so you probably want to add it back to the page).

After changing the vendor to 'Other' (the only other choice), the error doesn't seem to be occurring now.  Now, the fun part to see how persistent search interacts on imports.

Saturday, March 15, 2014

ServiceNow – Why is GlideRecord insert() returning a null

You’re trying to save your spiffy new record but var incSid = current.insert() is returning null.  Boo. 

To make matters more fun, this code is an Inbound Email Action.  One might suspect that the guy responsible for anything with the letters e-m-a-i-l in ServiceNow must really like creating puzzles or hate wasting disk space on silly things known as error messages.

The first thought is that it could be an ACL issue.  You don't have create rights to the table so that must be why it is failing.  The only problem with that theory is that you are an admin and  so theoretically the code is running in your authorization context.

So what now?  Bad data maybe?  Ok, so off to our friend 'Background Scripts'.  Let's try a field that doesn't exist
var x = new GlideRecord('incident');
x.u_something_that_cant_exist = true;

Well, that returned a sys_id and not null. But it did seem to return some log messages.

So, this was a fruitful path to investigate. I went ahead and replaced incident with the table in question and voila, we get an error message when running the background script:
Background message, type:error, message: Data Policy Exception:  user is mandatory 
*** Script: null
and there we go. The problem was that it wasn't a bad field but missing data in a mandatory field.