In the Lync 2010 world, everything was golden. Lync was pretty cool, and it integrated well with Exchange 2010. Then our senior admin upgraded the network to Lync 2013, and things changed.
Not a whole lot changed, but one thing changed that I kind of enjoyed doing: changing my avatar.
The problem is that in Lync 2013, in order for users to change their pictures, the Exchange environment needs to be 2013, otherwise, users will end up with something like this:
After doing a bit of reading, it turns out you can still have pictures, but the administrator needs to upload the pictures and/or somehow pictures need to uploaded into Active Directory.
So what I did — others more well versed may come up with a different solution — is I created my image, saved it into a network share on the Exchange server, and then ran this command in an elevated prompt in the Exchange shell:
Of course, with the appropriate changes to our environment.
Then I hopped over to the Lync server and in an elevated Lync shell, I ran
I don’t remember where I read those commands, but I did it because I read that Lync updates those items once every 24 hours, so I figured why not force it like doing a group policy refresh.
I did notice that the changes were being made to Exchange because Outlook changed my picture, but what gives with Lync? No answer was being found online, and I even removed the local Lync cache and still no luck.
Then I decided to try hiding my picture, clicking ok, then showing again (like in the image above). It appeared!
The only thing I can think is that was causing it not to work was that the cache wasn’t refreshing on the Lync server, so hiding and showing the image again somehow refreshes it.
Maybe. In any case, at least I can contribute this solution to the web.
Encountered two issues today that need to be noted real quick:
WSUS was giving me a ton of problems with not updating on client machines. Error after error, and I was completely puzzled because I had everything configured correctly. Turns out Microsoft change their port in WSUS from 80 to 8530, so in your internal addressing, you have to add that like this to make it work:
System Center 2012 R2 DPM was giving me problems with Replica Inconsistencies. So to fix this, I updated it, and found out that Windows Server Backup feature needs to be installed along with Visual C++, and possibly WinRE disabled. Links below.
First let me start off by saying that I am not a Sharepoint expert. I would consider myself far more adept at Windows server administration in regards to Active Directory, Hyper-V, and other areas within the Server 2012 world.
When it comes to Sharepoint, I’m putting this post together in hopes of revealing some of the issues that I’ve come across with in my migrating of a Sharepoint 2010 farm to Sharepoint 2013.
What is Sharepoint?
The best way that I can describe Sharepoint is that it’s a collaborative platform that is extremely robust, full of features and capabilities. Sharepoint can be a CMS, wiki, blog, file sharing tool, and more, along with built-in tools for searching, indexing, auditing, and….more. It’s highly customizable and is often used by developers to build tools and act a central repository for pulling information. Office, Exchange, Active Directory: all these other Microsoft services, and more, plug into Sharepoint.
Really, Sharepoint can be a bunch of things, and I might even be underestimating what it can do.
However, with all this capability comes a cost: Sharepoint can be a major pain in the ass. The devil is really in the details when it comes to designing and deploying a Sharepoint farm, and even more so when you’re trying to migrate Sharepoint.
Originally I was tasked with fixing the search feature in a Sharepoint 2010 farm, but the farm had two issues: the front-end search feature was completely broken, and the back-end had its own major problems. I was just suppose to get it working, which is easier said than done when you don’t really know what you’re doing — especially with Sharepoint. I figured my Google-Fu skills would get the job done, and it worked for the front end problems, but the back-end just wouldn’t work no matter what I did. Wanting to cut my losses and not waste anymore time, I told them that the farm should just be migrated (which is what they wanted to do anyways, but were hoping search would start working).
I had no idea what I was getting in to. I wouldn’t really call it a mistake, but I clearly had no idea of the immense amount of work needed to migrate a farm that had customizations (and still don’t, because I’m hardly done).
This is nothing like ad-preping an old domain controller, joining the new server to the domain and promoting it to a DC, then demoting the old box. Nope. It’s just not that simple.
Ok, enough of my whining. Let me get to the details of what I needed and what I encountered, because if you googled one of the issues I ran in to, you just want to get it going.
Priming the Pump
If you’re new to migrating Sharepoint (or Sharepoint), then I recommend immersing yourself in some content.
I would first recommend the book Professional Sharepoint Administration 2013 by Shane Young, Steve Caravajal, and Todd Klindt. I think for a tech book, the book is well written and is very readable, and it provides context and background information for aspects of Sharepoint like service applications, the hierarchy of farm to web apps, to site collections, etc. This is absolutely important if you’re trying to understand how the entire picture is put together.
Next, I would grab some video series and check out some videos. On my list:
Upgrading to Sharepoint 2013 by Shane Young – This was a great video for understanding the migrating process, and Shane certainly gives lots of information about the process, but his upgrade was far from normal and it went way too smoothly compared to my experience and what I’ve read online. Still, the video is gold.
I think those videos and the book really help set the stage for administrating Sharepoint, in particular for migration. The other thing is to get your hands dirty and install a few times — or have something break and think that wiping and reinstalling is going to fix everything.
The basic idea with migrating Sharepoint 2010 to 2013 is that you’re doing a database detach (backup and restore of the content database[s]), and reattaching it to a fresh farm. It’s in attaching it that you can start to run into issues.
The Devils I Encountered
The first issue that really caused problems with my install was migrating farm features and solutions from the old 2010 farm to the new 2013 farm. I thought I could just migrate it without the features and just have orphaned features and clean that up later. Well, I had problems, and I’m not entirely sure if that was a result of the failed features or something else (I believe it was something else, but it’s a good idea to fix the features). To find out what features you’re missing, run this:
Then you have to move those features to the 2013 farm. Within an elevated powershell prompt and in the directory with the features, run this code that will install the features into the farm (but it won’t deploy the features, that’s next):
For features that are missing, start googling the GUIDs and feature names. At one point I had to search deep, and for one feature I had to go to archive.org, down the MSI, unpackage the MSI and manually install the files and update the web.config. I think this is abnormal, but the feature I was looking for was gone and the website it came from had long been decommissioned.
Site Collection Not in Site Map
This problem caused me the most of amount of headaches. I kept getting this error after running Mount-SPContentDatabase:
“Database … contains a site [GUID] that is not found the site map. Consider detach and reattach the database.”
Ok. That’s weird, that’s not how it went in the videos! They just attached and went on their merry way deciding whether or not to upgrade the site collection. I kept having this issue after every database mount and upgrade; I checked that every mount point was correct, every alternative access mapping (AAM) was correct, and I even wiped and reloaded several times to get it working — all to no avail.
That was the problem. After trying to remap the site with an alternative access mapping, it turns out I can’t map to a host-named site collection.
WTF is a host-name site collection? I didn’t know there was a difference. Turns out there’s a huge difference and it’s why my site collection has failed to be mounted, because there was a mapping that had a name of the site collection that I was trying to mount to my web application. In other words, I needed to have my host headers with a different name for my web application.
After renaming my host headers to something that didn’t conflict with the site collection, I wiped the database from SQL and removed it from Sharepoint 2013, then I mounted the DB again.
And now I have a working site collection. I still to need to update it from classic authentication to claims, then test the site collection in 2013 mode, and then fix whatever else comes after that, but those two items above were the things that kept me hung-up the most.
Other Sharepoint Resources
Here’s some other Sharepoint resources that may be helpful:
Todd Klindt’s Blog – The man is a repository of endless Sharepoint information, a Jedi Master in Sharepoint. He has a listing of build/update numbers
Sharepoint Subreddit – These guys are just awesome. I’ve yet to be told to RTFM, but that doesn’t mean it won’t happen. These guys are genuinely helpful, and there’s even more helpful Sharepoint info the sidebar.
Script to Help Sharepoint Updates Go Faster – If you ever need to run Sharepoint updates, this script is the bomb. It essentially shuts down services that would cause the update to slow down, applies the patch, then restarts the services. If you have to run successive updates, I recommend restarting between updates.
Sharepoint StackExchange – I don’t really find this place helpful, but sometimes you never know! Questions get asked daily and most go unanswered. The Sharepoint subreddit is more helpful, IMHO.
One of the greatest threats to a young IT professional is skill atrophy. You work hard at developing a skill set over a given period of time, and you even go so far as to earn a certification in such a skill set — and then you quit using it.
The old appropriate is appropriate here: “Use it or lose it.”
Recently while working at a site, and much to my frustration, my skills in router and switch configuration — even just layer 2 and 3 protocols — had started to atrophy because I hadn’t touch a device in five months — then bam! I’m setting up not just layer 5-7 devices, but I’m also setting up layer 2 and 3. I’ve been working so long in the higher layers that I started to forget basics in layer 2 and 3.
The hard part is that it was something rather ridiculous. It was a layer 3 switch, and turned the gateway port into a routed port instead of a switched port, thinking that I would separate out a server farm from the layer 2 network that it was attached to through that port. Nothing was getting DHCP requests on this switch and it was frustrating me to no end, not to mention I had to local techs looking over my shoulder and just standing there wondering what was going on! In the end, it was by getting help from my boss and co-worker that lead me down the road to figure out what I had been doing wrong.
So how does one prevent skill atrophy? The obvious answer is to practice, but that may not always be an option, especially if you’re in an environment where the work constantly changes and you’re insanely busy (that’s my excuse at least). Perhaps doing Packet Tracer simulations — for CCNA folks like myself — would be really helpful here.
Another idea is just good documentation, even trying to take a snapshot in time to see what you were doing. Copy your configs and annotate the configs to explain what the heck you were thinking — even encouraging this at your company so that other techs, or future techs, can get an idea of what’s going on.
Asking for help is always an option, especially if you’re really stumped. Time wasted can never be taken back (it’s a sunk cost), so realizing you’re failing bad early on can help mitigate future problems. To quote Freakonomics writer Steve Levitt, “Fail quickly.” However, at the same time, realize your failure is also a learning and/or reinforcement opportunity and will make you a better IT professional.
And of course, there’s also a good IT professionals google-fu, but you should be relying on that constantly, otherwise, are you learning any of this stuff?
All this being said, I’ve learned my lesson and I’m better because of it.
Here’s my first installment of “What I learned This Week”. It’s just a collection of topics that I’m hoping to solidify into solid memories versus fluid, potentially lost ones.
Sysprep doesn’t work on upgrades. Sysprep is a tool used for imaging, and according to the error log generated after I attempted a sysprep on a Windows 8.1 machines that was upgraded from Windows 8, you cannot sysprep machines that were upgraded.