While executing the below mentioned powershell script, I will get the unique ID of the Azure Virtual Machine. I have a doubt with that. Even when I execute this script in the physical machine, I get an ID. I want to know,
what that ID exactly represents?
Is this ID unique for every machine?
Powershell Script:
$computerSystemProduct = Get-WmiObject -class
Win32_ComputerSystemProduct -namespace root\CIMV2
'BIOS GUID: "{0}"' -f $computerSystemProduct.UUID
The ID represents the System Information as a GUID.
This GUID is unique - for every machine.
See for reference
https://learn.microsoft.com/en-us/windows/desktop/cimwin32prov/win32-computersystemproduct
It's unique for every machine, and you can check the details here:
(Universally Unique ID) A 128-bit unique number generated by various
algorithms to identify hardware or software. Because the number is so
large, for all intents and purposes no two UUIDs can be the same. The
reason for UUIDs is that they can be combined from disparate sources
into one database without fear of duplication.
Related
I know that AAD application ID is unique in one directory (tenant). It is a guid and apparently should be unique in whole world but collisions may be. The question is: does Azure while generation AAD application ID validate whether it is unique across all others directories or not?
If you look at the official document for application property you would know application id is
The unique identifier for the application that is assigned to an
application by Azure AD. Not nullable. Read-only
How Azure Application Id Generated Uniquely:
Application Id (GUID) break down like this:
60 bits of timestamp,
48 bits of computer identifier,
14 bits of uniquifier, and
six bits are fixed
Total of 128 bits.
The goal of this algorithm is to use the combination of time and location (“space-time coordinates” for the relativity geeks out there) as the uniqueness key.
However, there’s a possibility that, for example, two GUIDs are generated in rapid succession from the same machine, so close to each other in time that the timestamp would be the same. That’s where the uniquifier comes in.
When time appears to have stood still (if two requests for a GUID are made in rapid succession) or gone backward (if the system clock is set to a new time earlier than what it was), the uniquifier is incremented so that GUIDs generated from the “second time it was five o’clock” don’t collide with those generated “the first time it was five o’clock”.
Once you see how it all works, it’s clear that you can’t just throw away part of the GUID since all the parts (well, except for the fixed parts) work together to establish the uniqueness. This is how all that works.
Note: Even sometimes network address also considered for GUID.
Our software runs on Linux and we need to create a mapping between Linux device name(something like /dev/sda1) and VolumeGUID as it appears in Windows, since we are examining Windows disks/partitions.
We get this information from MountedDevices Windows Registry subkey.
Problem occurs on Windows 2016, where Volume{GUID}s are no longer listed in MountedDevices subkey.
I managed to figure out, that Volume{GUID} is not a random GUID anymore(which is probably why they do not have to be stored it registry anymore), but it gets composed from data in the partition table.
In case of GPT, the VolumeGUID is actually a GPT partition GUID, which is great, because I can easily reconstruct those VolumeGUIDs.
In case of MBR, it is something like:
\?\Volume{46e21ed5-0000-0000-0000-100000000000}\
\?\Volume{46e21ed5-0000-0000-0000-104000000000}\
\?\Volume{46e21ed5-0000-0000-0000-108000000000}\
\?\Volume{46e21ed5-0000-0000-0000-20c000000000}\
...
Where 46e21ed5 is actually a disk signature, but I'm not sure what other fields mean. It looks like there's a partition offset (0x400 = 1024, and each partition is 1024MB in the provided example), but something does not add up for the last partition which has 20C00.
Does anyone have more information on this subject and how these volume GUIDs get composed? (Google does not find any information on this subject)
Regards
I am using snmpwalk to derive a subtree of management values. One of the lines reads, for example,
iso.3.6.1.2.1.25.1.5.0 = Gauge32: 10
but what does it mean? What device/function, ... corresponds to the OID iso.3.6.1.2.1.25.1.5.0, and what does the number '10' stand for?
How to find out completly general for ANY OID (not just for this exemplary one)?
You can use the snmptranslate command:
$ snmptranslate iso.3.6.1.2.1.25.1.5.0
HOST-RESOURCES-MIB::hrSystemNumUsers.0
Or you can do the lookup in reverse with -On:
$ snmptranslate -On HOST-RESOURCES-MIB::hrSystemNumUsers.0
.1.3.6.1.2.1.25.1.5.0
(Note that the iso. in the first look-up means the same as the .1. that the reverse translate shows)
As noted in the comments, yes, you need the MIB installed in order to do these lookups, see your device vendor for the MIB file download. From what I've seen with a generic install of net-snmp, you get most of what you already are looking for.
iso.3.6.1.2.1.25.1.5.0 OID provide number of logged in Users info.
Gauge32 is OID type, Gauge32 you can expect the data increases and decreases based on what real world information it tries to provide
10 means number of users currently logged in your system.
I am implementing VSS Hardware provider for ZFS based iSCSI Target. We have implemented AreLunSupported, precommitsnapshot and commitsnapshot etc functions and till this point it is working fine. But after this it is failing with "VSS_E_NO_SNAPSHOTS_IMPORTED" error in LocateLun method. and I think we are not filling Target LUN information properly.
My questions are:
How to find serial number of target LUN ? Do I need to mount newly created snapshot and then get the serial number ?
Do we need to fill interconnect, storage identifier information also or can I just pass NULL for these.
Q: How to find serial number of target LUN ? Do I need to mount newly created snapshot and then get the serial number ?
No, you should not mount the snapshot at this point. You should use an out-of-band mechanism to directly communicate with your storage (I'm assuming your 'ZFS based iSCSI target' is coming from a NAS box), probably a REST API call, to figure out the serial number of the snapshot.
Let me elaborate some more on serial number of the snapshot:
VSS expects the 'shadow copy' to be a concrete, real volume, similar to the primary volume (in your case an iSCSI target)
Since you are using ZFS snapshots, without dwelling much into your exact implementation, you have 2 options to obtain the serial number for a concrete LUN:
a. If your storage allows exposing a ZFS snapshot directory as a iSCSI target, the create that iSCSI target and use its Page83 identifier
b. If not, create a ZFS clone using the ZFS snapshot and expose that as an iSCSI target and use its Page83 identifier
Q: Do we need to fill interconnect, storage identifier information also
or can I just pass NULL for these.
For all practical purposes, it usually suffices to simply copy the VDS_LUN_INFORMATION for the original source LUN and only edit the m_szSerialNumber field with that of the target LUN (assuming that the product ID, vendor ID etc. all will remain the same)
This link explains in detail what is expected out of a VSS Hardware Provider implementation: https://msdn.microsoft.com/en-us/library/windows/desktop/aa384600(v=vs.85).aspx
Unique Page 83 Information
Both the original LUN and the newly created shadow copy LUN must have
at least one unique storage identifier in the page 83 data. At least
one STORAGE_IDENTIFIER with a type of 1, 2, 3, or 8, and an
association of 0 must be unique on the original LUN and the newly
created shadow copy LUN.
Bonus chatter (Answer ends at this point):
Now, #2(b) above might raise eyebrows since you are creating a clone ahead-of-time and it is not yet being used. The reason for this is, the above steps need to be performed in IVssHardwareSnapshotProvider::FillInLunInfo and this same VDS_LUN_INFORMATION contents are passed later to IVssHardwareSnapshotProvider::LocateLuns (VSS is trying to tell you to locate the LUNs that you earlier told it were the shadow copy LUNs). Hence, regardless of whether you will be using the clone or not in future, you must have the concrete LUN (iSCSI target) created upfront.
A silver lining to this is: if you are sure that the workflow of the VSS Requestor will never mount the shadow copy, then you can get away with this by faking some (valid) info in VDS_LUN_INFORMATION during IVssHardwareSnapshotProvider::FillInLunInfo. For this to work, you will have to create a 'transportable' shadow copy (the VSS requestor uses the VSS_CTX_FILE_SHARE_BACKUP | VSS_VOLSNAP_ATTR_TRANSPORTABLE flags). The only use-case for such a shadow copy would be to perform a hardware-resync on it, in which the VSS Hardware Provider implements the IVssHardwareSnapshotProvider::ResyncLuns method and performs a ZFS snapshot rollback in it.
I have an imap account, (e.g. some#gmail.com) and I know many libraries with which I can connect and replicate messages back to my destination. I want to achieve following,
First time, I want to download all messages (including sent folders), and when I download for the first time, I will save message with ID and UID locally in some database.
Second time, I do not want to query downloaded messages, even though their read/unread status or any flag or deleted flag is changed or they are purged.
Our aim is to download and sync every messages locally, once and only first time.
Now I know little about IMAP message that they have something called ID, UID and MessageID. ID is probably an offset in current folder, UID is numeric id in current account and MessageID is a unique string.
Now I want to know, what search I should use while querying folder, so that messages once downloaded, wont be returned back to me.
I am planning to use http://mailsystem.codeplex.com/ library, and it gives ability to Search with custom string and returns int array.
Assuming I have, a MaxID, and I want to only download messages which has ID or UID greater than MaxID. Which one should I use? UID or ID?
You should use the UID in combination with UIDVALIDITY. Both values are folder specific.
There is an informational RFC that describes how IMAP clients should do synchronization (RFC-4549, section 4.3). The text recommends issuing the following two commands:
tag1 UID FETCH <lastseenuid+1>:* <descriptors>
tag2 UID FETCH 1:<lastseenuid> FLAGS
The first command is used to fetch the required information for all unknown mails (without knowing how many mails there are). The second command is used to synchronize the flags for the already seen mails.
AFAIK this method is widely used. Therefore, many IMAP servers contain optimizations in order to provide this information quickly. Typically, the network bandwidth is the limiting factor.