Apple Watch Series 4 Stainless Steel (No Cellular) Availability

For a few days now the Apple Watch Series 4 stainless steel Wifi/Bluetooth (No-Cellular) has been out of stock in the Apple store.

Have anyone noticed? Or am I alone on this one? I ask because I have been googling around and I can't find anyone talking about this outage. Hopefully there will be more in stock by the holiday season arrives.

I am looking forward to get the 44mm Series 4 stainless steel WiFi-only in gold, similar to the one in this photo but with the stone gray sport band; preferably by this holiday season, but I haven't seen this version on the apple store. Does this version exists at all? LOL.

I will update this post if I hear anything, in case anyone else is interested in the availability on this particular model. In the meantime please tell me in the comments if you've heard anything or if you plan to get this version or the one with cellular (LTE).


UPDATE --
I just learnt via this Reddit post that there is actually NO Stainless steel GPS only (Non-cellular) version! I guess the only option now for me is to get the Stainless steel + Cellular version and just will not activate the LTE.
Thanks Apple! >;(

MOSS 2007: New Users Not Found On Select People And Groups Dialog Search

Since I spent so much time troubleshooting through this issue I thought it needed to be posted somewhere.

I heard complaints from some users about an issue when they tried to give permissions to new users joining the organization, in SharePoint. The issue seemed quite random and the first thing that came to my mind was to check the User Profile Synchronization.

We have a mid-sized SharePoint farm with 2 web front end servers and 1 application server running MOSS 2007.

The User Profile Synchronization seemed to be fine, and I couldn't find any errors in the crawl logs. I was able to find the users in the Shared Services Administration / SSP / User Profiles and Properties / View user profiles.

I was convinced that the users existed in AD and that SharePoint was able to import their profile properties.

These are the steps I followed to reproduce the odd behavior:

• Go to Site Actions / Site Settings / People and Groups
• Select the Site “Members” group from the quick launch
• Select from menu bar New / Add users
• At the Add users page I clicked on the Address book icon
• At the Select People and Groups Dialog box I searched for first name, last name or Domain\User id of a recently added user in AD

I've got the following message in red: No results were found to match your search item.

I found that I was able to grant permissions if I skipped the Select People and Groups Dialog Box that is, clicking the Address book icon and instead I type in the user ID in the standard Domian\User ID format, then clicking on "Check Names" icon to resolve the names at the Users/Group white box (or people picker).

This was our workaround to grant site permissions while I researched. Google search results didn't provide any solutions.

The next day I found that the users that wouldn't come up in the results at the Select People and Groups search, were showing up! I just couldn't make any sense out of it.

After several hours troubleshooting this issue and going nowhere, I thought of testing this straight from the MOSS servers, and I'm glad I did!

So, I looked for some user ID's recently added in AD and tested. I discovered that the odd behavior would show up when testing through any of the web front end servers, which they sit in the DMZ; while testing on the application server which lives guarded behind our firewall, would return the user search as expected.

This new information changed the focus of my troubleshoot effort. I thought that most likely, SharePoint servers in the DMZ were not able to talk properly with the AD server, but still it wasn't clear why sometimes the users were found; just like the next day when I tested and the users previously added to the permissions group where found in the same People and Groups search results regardless of the client machine or browser running the query.

More research revealed that there’s a hidden 'User Information List' at http://site/_catalogs/users/, apparently this list, which exists at the Site Collection level, gets populated when a user is given permissions over the site and/or they log into the site for the first time.

All my testing and the experienced behavior was pointing to the fact that there were two different mechanisms in play. The Users/Groups people picker's Check Names button, would validate and resolve the user straight at the AD, while the SPAG Dialog Box (Address Book icon) would 1)Attempt to validate against the User Information List, if the user was not found then 2) it would query the AD server. It was obvious that the latter was failing.

I asked our Network Administrator to help me troubleshoot this. He traced the network communication just as I search for a User through the SPAG Dialog box, and he discovered that the SharePoint server was trying to communicate with the AD server through specific ports that we're not allowed on the firewall rules.

The issue was resolved by setting firewall rules for ports 80, 3268 and a range of RPC ports.

Mystery solved!

Attaching WSS 2.0 content database to a MOSS 2007 Web application

I've been stuck all week trying to migrate a wss 2.0 content database to a MOSS 2007 dev environment, it's supposed to be a straight forward process; I followed the documented steps and every time I ended up with the content database, apparently well attached to the newly created web application, but under the "number of sites" column (content database page in CA) I had "0 sites"; when trying to browse to the site it would just redirect me to the 404 Page not found.

As background, a colleague of mine already went through this process successfully; he had a backup of the original wss 2.0 content database restored in the Sql development environment, he attached it to a web application with no issues. Since, users modified the original wss 2.0 site content, this effort was useless now and I had the task to do it all over again.

So, these are the steps I followed:

1) I've got (a fresh) backup copy of the original wss 2.0 site content database from my DBA, and have it restored in the Sql server in dev environment.

2)I attached this wss 2.0 content db to a MOSS web application, this process should convert the wss 2.0 databse schema to wss 3.0; for this step there is more than one way to do it:

• Create a new web application on Central Administration, then after the process ends go ahead and remove (deattach) the default content database created by SharePoint; attach the wss 2.0 content db using: stsadm –o addcontentdb –url -databasename -databaseserver
• Create a new web application on CA (let SharePoint create the content db), when finished remove the default database using CA; attach the wss 2.0 content database using the CA (manage content databases page).
• Create a new web application using the CA; this time, don't allow SharePoint to create a new database, change the default database for the wss 2.0 database which we want to migrate. This process should convert the wss 2.0 content database, but it might timeout forcing you to use stsadm tool.

So, I tried all of these steps and every time I would end with the same result; the database was attached to the web application, but the site was unaccessible.

Finally, I recalled about my colleague's previous effort, his web application was still there with the outdated, but yet same content database I was trying to migrate again.

After I de-attached that old content database from his web application and retried all the steps above, everything was fine!

I removed that old content database, and attached the fresh content database to my MOSS web application and I was able to browse immediately to the (now converted) wss 2.0 sites!

It seems that SharePoint is keeping some reference to each database attached to web applications in the config database; I took the time to test this scenario several times, and it seems you can't in fact attach a copy of the same database (even though is a different instance) into two different web applications in the same farm, SharePoint will notice this and won't allow you to access properly to the sites in the web application/content db you pair last.

I know it sounds weird, but that's how I was able to migrate my wss 2.0 site to MOSS.

If you happen to know more details about why this happens or a more elegant wording for what I just posted please throw me a line, I will update this page.