Hello? Are you there?

I guess you must have changed your

Presence policy.

Hey, everyone. Well, the Summer Solstice has come and gone, we're now well into summer itself, and right now the temperature in Redmond is 52 degrees Fahrenheit, and raining. How does that compare with the rest of the world? Well, in Fairbanks, Alaska it's currently 54 degrees (and not raining). In cold, damp London, England it's 63 degrees (and not raining), even though it's evening time in London. Fargo, North Dakota? 63 degrees and sunny.

Depressing? Of course. After all, those of you in Base Arturo Prat, Antarctica have to deal with 6 degrees and snow. And in Nome, AK it's only 42 degrees and cloudy. So, all in all, those of us here in Redmond consider ourselves pretty lucky.

Even if it is 59 degrees in Minneapolis-St. Paul. And 53 degrees in both Hammerfest, Norway and Reykjavik, Iceland.

But you know what they say. No, we mean besides "The weather in Seattle really sucks." They say, "It's always a good day as long as you have Lync Server PowerShell cmdlets to play with." Which means it's going to be a really good day here, because we have plenty of Lync Server PowerShell cmdlets to play with.

As noted, today promises to be an especially good day, partly because we have an all-hands meeting in less than two hours (hurray!) but also because today we're going to talk about the CsPresencePolicy cmdlets: Get-CsPresencePolicy, Grant-CsPresencePolicy, New-CsPresencePolicy, Remove-CsPresencePolicy, and Set-CsPresencePolicy.

If you're thinking to yourself, "What the heck is a presence policy?" well, don't feel bad: we're not totally convinced that anyone really knows what a presence policy is. Presence policies are used to manage two properties (that's right, just two):

MaxPromptedSubscriber. This is kind of an oddball one, but it works like this. By default, any time you are added to another user’s Contacts list a notification dialog appears on screen informing you of that you've been added to the list, and giving you the chance to, say, add the person to your own Contacts list, or maybe block that person from viewing your presence. Until you take action and dismiss the dialog box, each notification counts as a prompted subscriber. By default, Lync Server only allows you to have 200 of these undismissed dialog boxes at a time.

So would anyone ever have 200 undismissed dialog boxes at a time? Beats us. But that's the default value. If that seems too high (or too low) you can use the Set-CsPresencePolicy cmdlet to change the value (any integer value between 0 and 600, inclusive):

Set-CsPresencePolicy –Identity global –MaxPromptedSubscriber 500

So what happens if you exceed the number of allowed dialog boxes? Nothing really. You'll still get added to the other person's Contact list; you just won't see a notification that you've been added to the Contact list. If you set MaxPromptedSubscribers to 0 then you'll never see a notification when you're added to someone's Contact list.

MaxCategorySubscription. OK, this one's a little trickier, and probably a little more meaningful. When you add someone to your Contact list, you actually create a number of subscriptions that request presence information for that person: in particular, you ask to receive information for the other person's contact card, calendar data, notes, services, and current status.

Got that? In other words, for each person on your Contact list, you create 5 category subscriptions.

So what does the MaxCategorySubscription property (which has a default value of 1000) do? It determines the maximum number of subscriptions that can be made to any one user account. Take Ken Myer, for example. Using the default value of 1000 subscriptions, that means that 200 people can receive presence information for Ken (1000 subscriptions divided by 5 subscriptions per Contact list equals 200). Does that mean that only 200 people can have Ken on their Contact list? No, a million people can have Ken on their Contact list if they want. But suppose 200 people have Ken on their Contact list, which means his category subscriptions are maxed out. What happens if Pilar Ackerman tries to become the 201^st person to add Ken to her Contact list?

Two things happen. First, Ken will be added to Pilar's Contact list; there's no problem there. However, Pilar will not receive presence information for Ken; instead, she'll simply see a message stating the presence data is not available because Ken has reached his maximum number of followers. Ken will still be a valid contact; Pilar just won't know whether his status is Available, Away, or Do Not Disturb.

Now here's the tricky part. Suppose someone other than Pilar, someone who also has Ken on their Contact list, logs off of Microsoft Lync. Well guess what? That means that only 199 people are currently subscribed to Ken's account. In turn, that means that Pilar will now start receiving Ken's presence information: she's now number 200 on the list rather than number 201. Remember that guy who logged off of Lync? Well, if he logs back on, now he won't see Ken's presence information. Why not? Because there are already 200 subscribers ahead of him. It's first-come, first-served.

And yes, we know. But if you think about it for a bit, it will start to make sense. For example, suppose you want to use instant messaging but you don't want people exchanging presence information. That's fine; just set MaxCategorySubscription to 0:

Set-CsPresencePolicy –Identity global –MaxCatgeorySubcription 0

With that command you can still add people to your Contact list, but you won't be able to view their presence information.

Of course, maybe there are just certain people – for example, your executives – who don't want their presence information shared with the world. That's fine: that's why presence information is wrapped up in a policy instead of configuration settings. If Ken Myer is your CEO and he doesn't want his presence information shared with anyone all you have to do is create a new presence policy and set the MaxCategorySubscription property to 0:

New-CsPresencePolicy –Identity "ExecutivePresencePolicy" –MaxCatgeorySubcription 0

And then simply use the Grant-CsPresencePolicy cmdlet to assign that policy to the appropriate users:

Grant-CsPresencePolicy –Identity "Ken Myer" –PolicyName "ExecutivePresencePolicy"

That's all you have to do.

And that's all we have to do, too, at least for now. (But don't worry: we'll be back tomorrow.) In the meantime, the temperature here in Redmond has risen all the way to – uh, 52 degrees. But hey, it's only 48 degrees in Angmagssalik, Greenland. Bet you Greenlanders really wished you lived here, don't you?

I sense a very

Real connection between us.

CS Management.

Yesterday the author of today's haiku was the lone member of the user assistance (UA) team to sit in on a meeting. As such, he was almost immediately peppered with questions about documentation:

"Do you know who's going to be working on the documentation for this?"

"No."

"Do you know if you guys have started planning the documentation set for this?"

"No."

"Do you know when your team expects to have the documentation done?"

"No."

"Do you know who holds the Major League record for most runs scored in a career?"

"Yes. Rickey Henderson."

OK, no one actually asked that last question, which is too bad: after all, Rickey Henderson does hold the Major League record for most runs scored in a career. But no one ever asks the author of today's haiku about important things, like baseball or college basketball. Instead, they always ask him things about work priorities and deadlines. Work priorities and deadlines? Why would you ever ask someone who writes haikus about Lync Server PowerShell questions about work priorities and deadlines?!?

At any rate, if you want to know who holds the Major League record for most doubles in a season (Earl Webb), ask the author of today's haiku. But that's pretty much the extent of his knowledge. If you want to know something besides the name of the player who holds the Major League record for most doubles in a season, well, you'll have to ask someone else.

No, wait! As it turns out, the author of today's haiku does know one other thing: he knows what the CsManagementConnection cmdlets (Get-CsManagementConnection, Remove-CsManagementConnection, and Set-CsManagementConnection) are used for.

So what are the CsManagementConnection cmdlets used for? We were afraid someone was going to ask that. Well, as you probably know, most of the configuration information used by Lync Server 2010 is stored in a SQL database known as the Central Management Store. Where exactly is that SQL database? To tell you the truth, we have no idea. But the Get-CsManagementConnection cmdlet will typically tell you:

Get-CsManagementConnection

Run that command, and you will typically get back something similar to this:

StoreProvider : Sql

Connection    : DataSource=atl-sql-001.litwareinc.com\rtc;InitialCatalog=xds;IntegratedSecurity=True

ReadOnly      : False

So why do we keep saying that things "typically" work like this? Well, typically, you configure your SQL Server database (and, by extension, your management connection) when you install Lync Server and, from that point on, you never have to worry about either the database or your management connection. However, suppose that something does go wrong?

For example, suppose your database has crashed, and you need to point your management connection to a backup database. How do you do that? One way is to use the Set-CsManagementConnection cmdlet:

Set-CsManagementConnection -StoreProvider Sql -Connection "atl-sql-001.litwareinc.com\rtcbackup"

As you can see, that's not too terribly hard: you simply set the StoreProvider parameter to Sql and set the Connection parameter to the path to the backup database. Will you ever have to do that? Probably not. But it doesn't hurt to know that you can do that, if need be.

Here's something else that you'll probably never need to do, but can: you can actually set your management connection to the local file store. In that case, you'll do all your work locally and will not be connected to the Central Management Store:

Set-CsManagementConnection -StoreProvider FileSystem -Connection "C:\Test"

So why would you ever want to do that? Well, two reasons. One, it gives you a test environment where you can play around with doing things like creating and deleting policies, all without ever affecting the real Central Management Store. For example, if you create a new voice policy, that policy won't get stuffed into the Central Management Store where another administrator could inadvertently start assigning the policy to actual users. Instead, it just becomes an XML file on your local hard disk. A good, risk-free way to play around with Lync Server PowerShell.

Another possibility is this: you need to create a bunch of new policies and stuff, but your network is having problems and you can't connect to the Central Management Store. Well, if you wanted to, you could switch your management connection to the file system, create your policies, export them to a slightly-different XML format, and then later (after the connection has been restored) import them to the Central Management Store.

OK, good question: what does that mean? Well, it means that you could do something like this:

$x = New-CsExternalAccessPolicy –Identity "TestExternalAccessPolicy"

Export-Clixml –Path C:\Test\TestExternalPolicy.xml –InputObject $x

All we've done here is create a new external access policy and stored it in a variable named $x; we then use the Export-Clixml cmdlet to save that policy to an XML file named C:\Test\TestExternalPolicy.xml.

What's the point of that? Well, let's suppose the network is back up and running, and we've switched our management connection back to the Central Management Store. Is there an easy way to get this new external access policy into the Central Management Store? Of course there is:

$x = Import-Clixml –Path C:\Test\TestExternalPolicy.xml

Set-CsExternalAccessPolicy –Instance $x

As you can see, we've imported the policy, stored it in a variable named $x, then used the Set-CsExternalAccessPolicy cmdlet to save that policy to the Central Management Store. Again, this might not be something you'll ever find yourself doing, but, hey, stranger things have happened, right?

By the way, how do you switch back to using the Central Management Store as your management connection? By running this command:

Remove-CsManagementConnection

Yes, that looks dangerous, doesn't it? But it's not. If you don't specifically define a management connection then Lync Server PowerShell automatically looks in Active Directory to see if it can find a service control point that reports the path to the Central Management database. Assuming that this service control point can be found, then your management connection will automatically point towards that database.

Two quick notes about this. First, you can only change the management connection for your local computer; you cannot remotely connect to another machine and change its management connection.

Second, any change you make to your management connection lasts only as long as your current instance of Windows PowerShell. Suppose you switch your management connection to the file system and then exit the Lync Server Management Shell. The next time you start the Management Shell, your management connection will once again point to the Central Management Store. (Why? Because the Management Shell retrieves the service control point from Active Directory each time it starts up.)

And there you have it: now you know all about the CsManagementConnection cmdlets. Oh, and you also now know that Ty Cobb holds the Major League record for most triples hit in a career. Is there anything else that you need to know? Not that we can think of.

See you tomorrow.

Daylight beckons but

The windows just won't open.

Audio testing.

Happy Summer Solstice everyone! Yes, today is June 21^st, which means it's once again the Summer Solstice, the longest day of the year.

At any rate, as the day with the most daylight of any day of the year, the author of today's haiku is spending his Summer Solstice sitting in his office (the one with the windows that are designed not to open) writing today's Lync Server PowerShell haiku. That, by the way, is exactly how the ancient Druids used to spend their Summer Solstice.

In case you're wondering, the reason we have a Summer Solstice in the first place (that is, the reason that days vary in their amount of daylight hours) has to do with the fact that the Earth is tilted somewhat in relation to the sun. (Many of the people on the Earth are also tilted, although that's a different story.) This tilting is known as the "obliquity of the ecliptic." When the author of today's haiku was a freshman in college (back in the days when people still believed that the sun revolved around the Earth) he took an astronomy class. At one point in that class the professor said that, "Guys, if you want to be irresistible to women, just remember this: the obliquity of the ecliptic in 23-and-one-half degrees." Ever since then, the author of today's haiku has remembered that the obliquity of the ecliptic in 23-and-one-half degrees. Has that made his irresistible to women? Well, actually he – say, aren't we supposed to be talking about Lync Server PowerShell here?

In honor of the Summer Solstice (Latin for "sun standing still"), we thought we'd talk about the CsAudioTestServiceApplication cmdlets: Get-CsAudioTestServiceApplication and Set-CsAudioTestServiceApplication. As it turns out, these were the two cmdlets most often used by the ancient Druids. Why? Well, the ancient Druids liked the fact that Microsoft Lync 2010 gave them an option to test their network connections before they actually tried to make a phone call. How did they do that? That's easy: from the Microsoft Lync Contact window they opened the Options dialog box, clicked the Audio Device tab, and then clicked Check Call Quality. A call would then be placed to an "audio bot" which would answer the phone and ask the Druid to record a short message. That message would then be played back, and the Druid could decide for himself (or herself) if call quality was up-to-snuff.

Of course, if you start up Microsoft Lync and click the Audio Device tab, you might not see the Check Call Quality button. Is this yet another example of advanced technology (such as time barrier gates) that were possessed by the Druids but have been lost to the ages? No. Instead, you'll only have the Check Call Quality button, and the ability to make a test call, if you install the Audio Test Service, something you can do by running Ats.msi, a file found in the Lync Server setup folder.

When you run Ats.msi, you'll not only get a new service, but you'll also get a new contact object representing your audio bot. This, in turn, is where the CsAudioTestServiceApplication cmdlets come into play.

Before we go any further, we should note that installing the Audio Test Service is the only way to get one of these audio bots (and, by extension, one of these contact objects); there is no New-CsAudioTestServiceApplication cmdlet.

However, there is a Get-CsAudioTestServiceApplication cmdlet, which enables you to retrieve information about your audio test contact objects. Need to see detailed information about each one of these objects? Then just run this command:

Get-CsAudioTestServiceApplication

If you'd rather see information just for a specific contact object then use a command like this one, which includes the Identity parameter and the contact object's SIP address:

Get-CsAudioTestServiceApplication -Identity "sip:RedmondAudioTest@litwareinc.com"

And here's an exciting one. This command returns all the contact objects that use US English (en-US) as their primary language:

Get-CsAudioTestServiceApplication | Where-Object {$_.PrimaryLanguage –eq "en-US"}

Man, those ancient Druids really knew how to live, didn't they?

Meanwhile, the Set-CsAudioTestServiceApplication provides a way for you to modify the properties of a contact object. For example, this command changes the primary language for a contact object to French:

Set-CsAudioTestServiceApplication -Identity "sip:RedmondAudioTest@litwareinc.com" –PrimaryLanguage "fr-FR"

And this one changes the contact object's SIP address:

Set-CsAudioTestServiceApplication -Identity "sip:RedmondAudioTest@litwareinc.com" –SipAddress "sip:USAudioTest@litwareinc.com"

And so on and so on.

By the way, contact objects are a little unusual in that they include a number of properties that are real, live properties, but don't actually mean anything. For example, you can set these property values if you want, but they won't actually do anything:

·         DisplayNumber

·         LineUri

·         SecondaryLanguages

These properties exist only because they are properties of the underlying Active Directory object that the audio bot contact objects are derived from. But they make absolutely no difference: you can assign 10 million different secondary languages to an audio bot, but that bot will never use any of those secondary languages.

Ever.

That's about it for the CsAudioTestServiceApplication cmdlets. As for the Summer Solstice, here's an interesting piece of trivia for you. The Druids referred to the first full moon in the month of June as the "Honey Moon," and believed that this represented the best time of the year to gather honey. In turn, this honey was fed to newly-wed couples as a way to encourage love and fertility. And that is where the notion of a "honeymoon" came from.

Well, we thought it was interesting. Or at least one of us did.

Basketball, noodles,

And conference directories:

Happy Father's Day!

We know that everyone out there is just dying to hear how the author of today's haiku spent his Father's Day yesterday, so here goes. Father's Day morning was very exciting: the author of today's haiku went out to the Black Lagoon (the corner of the yard that gets no sunshine but, being the first flat spot in the neighborhood, does get all the runoff from all the other yards on the street) and pulled weeds.

A whole bunch of weeds.

In the afternoon, father and son went to the gym to play basketball. Dad won several games of H-O-R-S-E, relying on his ability to score from behind the basket and to – twice – make a shot from three-quarters court. He also relied on his ability to make the humble free throw: on two different occasions he clinched a game when his son was unable to make even 1 of 2 free throws. Interestingly enough, in the one game of H-O-R-S-E that his son did win, the son got the winning basket by bouncing the ball from the free throw line. Dad suggested that, from now on, maybe his son shoot all his free throws by bouncing the ball, and – for once – his son actually agreed with him.

After playing H-O-R-S-E for a while, the two then played a game of one-on-one. Who came out ahead in that battle? Who knows? After all, it was just a friendly game of one-on-one between a father and his son.

And then, that evening, the author's wife made dinner: spaghetti with homemade noodles. How did that go? Let's put it this way: about as well as the game of one-on-one went.

But the food at the restaurant was top-notch.

Finally, we capped the day off the way all families cap off their Father's Day festivities: by running the Import-CsLegacyConferenceDirectory cmdlet.

Actually, we should clarify that a little: we should probably say that running the Import-CsLegacyConferenceDirectory cmdlet is the way most families cap off their Father's Day festivities. We say that simply because this cmdlet is only used by families (or organizations) that are simultaneously running both Microsoft Lync Server 2010 and Office Communications Server 2007 R2. If you've already migrated the whole family to Lync Server, then there's no need to run Import-CsLegacyConferenceDirectory.

Why not? That's an easy one: because Import-CsLegacyConferenceDirectory is used to keep your Lync Server conference directories in synch with your Office Communications Server conference directories.

To be a little more specific, Import-CsLegacyConferenceDirectory uses WMI (remember WMI?) to read legacy data from Office Communications Server 2007 R2, then uses that data to create corresponding objects in Lync Server: in other words, for each conferencing directory found in your installation of Office Communications Server 2007 R2, a corresponding directory will be created in your new installation of Lync Server. It's just like human cloning, other than the fact that it's not the least bit like human cloning.

It's recommended that you run Import-CsLegacyConferenceDirectory anytime conference directories are added, deleted, or moved in Office Communications Server 2007 R2. The cmdlet should also be run anytime Merge-CsLegacyTopology is run; this helps to ensure that the conference directories and the topology remain in sync.

And how exactly do you run the Import-CsLegacyConferenceDirectory cmdlet? Like this:

Import-CsLegacyConferenceDirectory

If you're wondering where all the other parameters are, well, there really aren't any other parameters: all you need to do is call the cmdlet and let Import-CsLegacyConferenceDirectory take it from there. But what if you're dead set on using additional parameters? Well, in that case, we suppose you could tack on the Report parameter, which lets you specify the file path for the report that gets generated when you run Import-CsLegacyConferenceDirectory:

Import-CsLegacyConferenceDirectory –Report "C:\Logs\ImportDirectories.html"

But that's up to you, and definitely isn't something you have to do.

Speaking of which, we should also note that there is one thing that you do have to do. Before you can run Import-CsLegacyConferenceDirectory, you must first install the Windows Management Instrumentation (WMI) Backward Compatibility interfaces package; this application is installed by running OCSWMIBC.msi. (Where do you get that file from? From the Lync Server Setup folder.) After installing the Compatibility interfaces package, you should next run Merge-CsLegacyTopology. And then, at long last, you and your son can run Import-CsLegacyConferenceDirectory.

And there you have it: the story of Import-CsLegacyConferenceDirectory, and the story of how the author of today's haiku spent his Father's Day. But don't worry, even though Father's Day is over, the author's son won't forget his dear old Dad.

Or at least he won't forget his dear old Dad's wallet.

See you tomorrow.

Together at last:

Microsoft and Google, and

Network region links.

Remember that big thing about Microsoft buying Skype? Well, you can forget that. Here's something even bigger: Microsoft has bought Google!

Or maybe Google has bought Microsoft; to be honest, the details are a little hazy. All the author of today's haiku knows at the moment is that he has won 950,000 British pounds in the Microsoft and Google Anniversary Contest. As his award notification points out:

"Microsoft and Google is now the biggest search engine worldwide and in an effort to make sure that it remains the most widely used search engine, we ran an online e-mail beta test which your email address won 950,000,00. GBP {Nine Hundred And Fifty Thousand Great British Pounds}"

Pretty cool, huh? At the current exchange rate, 950,000 pounds equates to a little over $1.5 million; for the author of today's haiku, that's like two years' pay! And that's just for the beta test of the contest. Imagine how much he could have won if he'd won the real contest!

Of course, you might be thinking, "Well, that all sounds nice, but there's no way that the author of today's haiku could meet the requirements for winning the contest." Au contraire, naysayers: not only did the author of today's haiku meet the requirements for winning the contest, but he also passed the "… statutory obligations, verifications, validations and satisfactory report Test conducted for all online winners." So there!

At any rate, the author of today's haiku has often wondered what it would be like if Microsoft and Google combined forces to produce a single search engine, and now he knows: he'd end up with $1.5 million.

Which is just exactly what he deserves.

What do you mean, "I bet this is some kind of a scam." How could it be a scam? After all, the prize notification included both a file reference and a batch number:

FILE REF: HL/5564/08/09/MICS
BATCH: MC11/834/5PDH /EU

And here's an interesting piece of trivia: the file reference and batch number are exactly the same as the file reference and batch number of someone who won a completely different contest! What do you suppose the odds are of that?!?

At any rate, while we wait for the " … Courier Delivery Of your Certified Winning Cheque Name" (and yes, that is a little disconcerting: we'd prefer to get the actual check rather than just the name of that check) we thought we'd talk about the CsNetworkRegionLink cmdlets. (That's right, the Microsoft Google Anniversary Contest and the CsNetworkRegionLink cmdlets, all in one day!) For those of you who like to keep track of this sort of thing, there are four CsNetworkRegionLink cmdlets:

·         Get-CsNetworkRegionLink

·         New-CsNetworkRegionLink

·         Remove-CsNetworkRegionLink

·         Set-CsNetworkRegionLink

And why do we even need any network region link cmdlets? We're glad you asked that question. Network region links are used as part of Call Admission Control, the technology introduced in Microsoft Lync Server 2010 that enables administrators to manage bandwidth use between two network regions.

Let's assume that you have two network regions – Northwest and Europe – and that the network connection between the two regions is a little shaky at times; because of that, you've created a bandwidth policy that places a limit on the amount of audio/video traffic that can travel between the two regions at any given time. That's good: we now have two regions, and we have a policy that limits audio/video traffic. That leaves us with just one problem: how do we apply that policy to traffic that travels between the Northwest region and the Europe region?

How do we do that? Hey, what do we care? After all, we just won $1.5 million; you can figure this one out yourselves.

No, hey, just kidding. The answer, of course, is that we create a network region link between the two regions, and then assign the bandwidth policy to that link. Why wouldn't we assign the policy to the two regions instead? Well, remember, there isn't anything wrong with either the Northwest region or the Europe region; we just have problems with the connection between the two. By creating a link and then assigning the policy to the link, we're able to place some limits on that one connection. Suppose we have an Asia region as well, but our connectivity between Europe and Asia and between Northwest and Asia is perfectly fine. That's great: in that case, we don't place any restrictions on those links. See how that works?

At any rate, the New-CsNetworkRegionLink cmdlet makes it pretty easy to create a network region link:

New-CsNetworkRegionLink -Identity NorthwestToEurope -NetworkRegionID1 Northwest -NetworkRegionID2 Europe -BWPolicyProfileID RestrictedAudioVideoTraffic

We told you it was easy, didn't we? Basically all we need to do is give the link itself an Identity (NorthwestToEurope) and then specify the two regions using the parameters NetworkRegionID1 and NetworkRegionID2. (Does it make any difference which region gets tabbed as region 1 and which one gets tabbed as region 2? Nope.) We then assign a bandwidth policy using the BWPolicyProfileID parameter. What if you don't know the Identities of your bandwidth policies? That's OK; just run this command:

Get-CsNetworkBandwidthPolicyProfile

That's really all there is to it. If you need to make a change to this link somewhere along the way (for example, if you want to use a different bandwidth policy) just use the Set-CsNetworkRegionLink cmdlet:

Set-CsNetworkRegionLink -Identity NorthwestToEurope -BWPolicyProfileID LessRestrictedAudioVideoTraffic

As you might expect, Remove-CsNetworkRegionLink deletes the links defined by any two regions (while leaving those regions exactly as-is), and Get-CsNetworkRegionLink returns information about your existing network links. For example, this command returns information about all your links:

Get-CsNetworkRegionLink

And this command returns information about all the links that use the policy RestrictedAudioVideoTraffic:

Get-CsNetworkRegionLink | Where-Object {$_.BWPolicyProfileID –eq "RestrictedAudioVideoTraffic"}

And so on and so on.

Before we go, we should also note that, as much as we'd like to, we cannot share our winning PIN number with you, thus giving you a chance to try and stake a claim to those 950,000 British pounds. As our notification email states:

"The Microsoft and Google Promotion Award Team has reached a decision from headquarters that any double claim discovered by the Lottery Board will result to the canceling of that particular winning, making a loss for both the double claimer and the real winner, as it is taken that the real winner was the informer to the double claimer about the lottery."

Hopefully you'll understand why we can't take any chances here. After all, the email concludes that we must " … keep your winnings strictly confidential until you claim your prize."