If you've worked with property keys, say with Windows Portable Devices, you've probably run across this macro. The Sensor platform would require you to define your own property keys if, say, you want to define a custom sensor data type. This macro isn't currently well documented (we're working to fix that), so it can be a bit confusing to use.

Here's the current macro definition from Propkeydef.h:

#ifdef INITGUID
#define DEFINE_PROPERTYKEY(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8, pid) EXTERN_C const PROPERTYKEY DECLSPEC_SELECTANY name = { { l, w1, w2, { b1, b2,  b3,  b4,  b5,  b6,  b7,  b8 } }, pid }
#else
#define DEFINE_PROPERTYKEY(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8, pid) EXTERN_C const PROPERTYKEY name
#endif // INITGUID 

When using this macro, you basically have two options:

1. Include Initguid.h in your project. In this case, the macro will declare the property key names and define the property keys for you. This approach works in most cases, but can cause naming collisions in large, complex projects.
2. Do not include Initguid.h. Instead, compile your definitions into a static library file having a .lib file name extension. In this case, the macro will simply declare the names for your property keys for the compiler's use, but you will need to reference your .lib file in your project's linker settings. This approach works best in large projects that use multiple modules, because it avoids the naming collisions mentioned in option 1. 

Using the macro without including Initguid.h and without referencing a library file will raise the error LNK2001, so if you see that error for your property key declarations, now you know what to do about it.

By the way, the property keys declared in Sensors.h are defined in Sensorsapi.lib. So, you can see that the sensor team chose option 2 when coding the platform.