I installed iOS 5 on my iPhone 3GS. It was a rough start, but I am happy with the end result.
For the last several iterations of the iOS on my 3GS has really slowed it down. The latest 4.3.5, slowed down my phone so much that I was thinking Apple was purposely slowing down the 3G series phones to force them to upgrade to the 4S. Unlike Microsoft that benifits from speeding up old hardware, Apple requires new products to be moving all of the time to keep their stock price up, and their company solvent, as no one can install their OS or use their software on anything other than Apple provided hardware... and Jobs said that Bill Gates was too uptight.. So slowing down older hardware would be right in their best interests, and therefore not a large logical leap to assume it was happening.
With iOS5, I found that my phone not only performs much faster, the battery life and the signal strength seem to have improved as well. I can't yet tell about calls dropped, as I have not had the time to really test that particular annoyance of the iPhone out completely. Weather this is simply a new algorithm used to compute the signal and battery strength I have no idea. I do remember seeing my signal strength greatly improve when I installed iOS4, only to be disappointed later when I found out that Apple was displaying strength greater than what the strength really was. This could be more of the same, but I want to believe that Apple has improved their software and thus found ways to improve their power usage, and to detect signal.
The new features are very welcome, especially the new camera features. The camera can now be accessed from the locked screen and you can take a photo by pressing the up button on the volume hard button. Infinitely easier to take a photo of yourself using this method than trying to find the soft button. I would always miss and end up in the photo album...
The new notification center is also very cool. You get a plethora of app data in there accessed by simply pulling it down from the top where the clock usually is. I know this is a feature they stole from Android, but it is a welcome addition.
Being able to choose how notifications are done is a great change as well. You can have your less important push notifications sent to a banner rather than to the non modal alert box. Very nice very good.
Apple is pushing iCloud, but I really am not very interested in that. I might be later, but right now... Meh.
The final new feature that I really like is that you no longer need to attach the phone to iTunes to update the software. This is a BIG help. However it kind of spooks me, because of my experience with updating my phone to iOS5.
During the install, my phone crashed, and I had to restore it back to factory preset, then I had to restore my settings and Apps. Then I had to put those apps back in to their folders. That took a long time and it sucked. Double sucked... If I were performing this update with out iTunes, would I be out of luck? With iTunes, I get a backup and I can restore the phone to somewhat of a state that it was in before. With out iTunes, will the phone just puke and then be dead? Something to think about... I know you are thinking, what about the backup that is made on iCloud. Think about it, what if I do a phone update somewhere I don't have access to a computer with iTunes for some time. Without the computer, I can't set the phone back to factory then do the restore of the phone. Will the phone just be toast until I can find some computer to plug it in? Or does the phone update by throwing everything in to memory... Sounds very inefficient, and lots of security problems come immediately to mind, but that never bothered Apple before...
All in all, good update, and I reccomend it for all of the iPhone 3GS users out there. With this update I think I can put off getting the next version of the iPhone until iPhone 5 comes out.
Thursday, October 13, 2011
Wednesday, October 5, 2011
Hiring for SharePoint
I am at the SharePoint 2011 Conference this week and I have found a reoccurring theme popping up with the manager types that come to the conference. Most of them are overwhelmed with the breadth of the SharePoint product, and nearly all of them realize that what they have in place to support SharePoint is not what they need.
I was talking to some of the other participants about a particular project they were involved it. He was involved in trying to deploy SharePoint as a fault tolerant system, and I was running down what he needed to do. We noticed that we were attracting a lot of attention from the leader types. You know, they are the guys in the button up shirts trying not to look lost in the sea of geeks. After a bit, the managers started to ask about how they could go about hiring the right people to set up their SharePoint environments "right." The first thing I said was that to set up their SharePoint environments "right," they needed to spend some serious money. In my experience, SharePoint needs a dedicated cross-functional team in order to be successfully deployed and maintained. The word that really stuck in the manager's craw is "dedicated." Even after seeing all of what SharePoint can do, they still believed that there would not be enough work for dedicated staff. This just isn't true. At any company were there is not dedicated SharePoint staff, immediate problems start to pop up, mostly surrounding the direction of the product, and what it can do. If staff is not dedicated, there is no incentive for an individual to study the features of SharePoint, and find out how it can be best used in the company. There is no one to support the product, leaving the end users wondering how to use it. Essentially, if you don't have dedicated staff, you are throwing the product down the tubes, and dooming your deployment for failure.
As to the hiring question... This spawned a long and interesting conversation about how many people were needed, getting input from the tech side, me, and the business side, them. All in all, those that accepted the fact that they need dedicated staff saw value in the team that I suggested.
In my ideal deployment, and this means ANY deployment, from one server to 10,000, you are going to need four roles; Architect, Administrator, Designer, and Developer. The most important, most senior, and most critical is the Architect role. This person will lead the team, develop the overall vision of the deployment, be the chief evangelist, and mentor the other roles. As you can imagine, this role is also the most difficult to hire.
Architect
This should be the first person that is hired, and should do the hiring for the rest of the team. This is a special person, because they need to have a split IT personality. In that I mean that they need to have experience with software development, and systems administration. It helps if they also have some Network Engineering in their background as well. What I mean by software development experience, is that they need to have a firm grasp of OOP, the .NET Framework, and modern design principals. They need to have written code as a developer on a software team. A person who has written code, but as a one project, one programmer shop is not your ideal candidate, as these developers often have a tough time leading a team of people.
They need to have designed and written WCF services, web services, and windows services. They need to know the role that each play, and how to integrate them in to a cohesive SOA. After all that... They need to have a good grasp of the SharePoint API, and they need to have written and deployed the major pieces involved in SharePoint development. What major pieces? Web parts, timer jobs, site definitions, and workflows. They need to know what each part does and what problems each solves.
The Architect should be able to speak to the database staff about indexes, backups, and SharePoint database architecture. They should also have a good grasp of what Remote BLOB storage is and when it is a good idea. They should be able to present this to the database staff.
On the other side of the IT fence, the Architect needs to know how SharePoint is installed, configured, deployed, and maintained. In other words, this person needs to have spent time as a professional SharePoint Administrator. As an administrator this person should have handled at least one major farm migration. This will ensure that they know what is involved in a migration, and that they have all of the lessons learned from that migration. It also ensures that they have been involved in SharePoint long enough to have seen where Microsoft has come with the product, and have some idea on where Microsoft is going with the product.
They need to have planed for and executed disaster recovery plans with SharePoint, and should be very comfortable with recovery scenarios, from a total loss of the farm, to the loss of a single file.
They should be well versed on search. How SharePoint does it, what the limitations of the Out Of the Box search features are, and when it is a good idea to put FAST Search in. They should know how to configure search so that it will return the proper results.
They also need to be a very well rounded IT person. They should know about the different methods on how to make SQL redundant, they should know how to load balance a web server, they should know what LDAP is, and what a good Active Directory design consists of and how it will impact the SharePoint deployment.
With all of this experience, it will be very difficult to interview for this position. You have to accept that the SharePoint stuff you will have to simply ask about and hope that they give you a straight answer. You are an IT manager, so hopefully you have some skill in the area of bullshit detection... If you have development staff, bring in a developer to aid in the interview. You will get a good grasp of their development skills from your trusted developer. Also bring in one of your Systems Engineers to find out what they know about AD and other Windows related services. If you have web staff, bring one in to discuss web topics. Your trusted staff should be able to give a good rundown on the candidate's general skill. From this you should be able to judge if the candidate is being truthful about what is on their resume.
Here are some of the qualities that I think that an Architect should have personally:
With all of the above, you must realize that this person will not come cheap. This kind of skill comes at a premium, and you have to giver proper incentive for them to stay. The good news it that you can save money on the other members of the team.
Administrator
The Administrator position is going to be easier to find. You can ask for some SharePoint administration experience, but it really isn't required, especially if you want to save some money on this position. In a perfect world, this position will have about 2 years experience with SharePoint as an IT pro.
The necessary skills, in my opinion, are going to center around, in order of importance, IIS, PowerShell, software deployment, Windows, and experience supporting "N" tier applications. SharePoint experience would fit somewhere between Windows and supporting "N" tier applications.
IIS is the key in this position, because SharePoint is a .NET program hosted in IIS. Without a firm grasp on how IIS works, how applications are hosted, how WAS works, the administrator will fall flat on his face when the fit hits the shan. SharePoint deals heavily in Web Services and WCF and if the administrator has never supported those two things in IIS, they will be baffled on why the sections hosting the different technologies use the same authentication, but have different settings in IIS. Without web experience, the critical difference between a web application and a web site will trip them up. These things are vital to the SharePoint farm.
I would like this person to be up on the latest load balancing techniques so that they can put in to practice the load balancing methods that the Architect selects for the deployment, but this is not necessary and it can be something that the Architect mentors the Administrator on.
Experience with PowerShell is absolutely vital. Much of SharePoint administration is done through PowerShell, and many tasks can be automated with PowerShell. Being only one person, the Administrator who only uses Central Administration can only do so much. The Administrator who automates and scripts tasks multiplies their worth to the company, by being able to clone themselves many times over. Also, many tasks need to be handled off hours, the stupid Administrator stays late, or remotes in from home to complete these tasks via Central Administration. The smart, savvy Administrator, the one you want to hire, scripts all off hour tasks and has the script send him email confirmations of task completion or failure. No muss no fuss. An Administrator that automates the most common tasks also builds in automatic redundancy for themselves and has more time to focus on interesting and important work, R&D, and preventative maintenance. The administrator who does not script is constantly putting out fires, repeating the same tasks over and over, and never seems to have any time to R&D and do anything preventative.
As the developers will be handing the Administrator their code to deploy, it is a good idea to look for an IT Pro with experience in deploying software. Again, you want to see this person insist on scripted deployments, as well as packaged solutions. It makes their job easier, and makes a solid repeatable, predictable deployment the rule rather than the exception.
Supporting "N" tier applications forces the Administrator to always be thinking about what service is calling what. It also will mean that the candidate knows about authentication methods that can handle multi-server hops, or what must happen so that authentication methods that can not multi-hop on their own make those vital hops.
Developer
Again, it is not vital that the Developer have SharePoint development experience. It is vital, however, that the Developer have .NET web development experience. From the developer standpoint, SharePoint is just another API to call. Take away the funky deployment, and SharePoint development is just like any other development, inherit a base class, and implement a method. A week training class will get the Developer up to speed on SharePoint development. After that the Architect will be able to mentor them and guide them to become SharePoint developers.
What we do want out of a developer is a deep sense of curiosity. We want them to want to know why things work the way that they do, and once they know that, they should wonder how they can manipulate those things to fit what the business wants to do.
Designer
The most common flaw that very technical people have is that they have no eye for the aesthetic. Their art is in their code, or in how smoothly their servers run. Unfortunately, no matter how brilliant the code behind the site may be, if it is not pleasing to the eye, or if the user experience is bad, the deployment will fail. This is where the Designer comes in. The designer is a person who should be able to design functional, pretty, web sites. I also like my designer to be experts in the client side scripting languages that make their visions possible. JavaScript, JQuery, CSS, Flash, and Silverlight should be on the Designer's resume along with the ability to work with technical people. In my opinion the designer should be able to create a UI, then hand that UI off to the developer to wire up the functionality. In other words the Designer creates the button and puts it on the page, the Developer takes over at the mouse click.
It is not required that the Designer know about SharePoint. SharePoint experience is good, but it is far from the most vital thing you are looking for.
DBA
This last position is not listed above on my three position team list because this position does not need to be 100% dedicated to SharePoint. SharePoint handles most of the database work all on its own, with as little human interaction as possible. BUT since a major part of the SharePoint functionality depends on the database it is important to have a DBA that can be the "go-to" person with SharePoint team issues. It will be up to the DBA and the Architect to make the redundancy decisions with regards to the SQL farm. If the Developer needs to hit an external database for some reason, the DBA is who they go to to get permissions and other things in line. When the Administrator is setting up Business Intelligence, they will need the DBA to create data cubes in Analysis Services.
With these positions filled, your SharePoint deployment is set up for success. SharePoint is a unique product, and not one that can simply be thrown in to an environment. It needs dedicated people to support and maintain it so that you can get the most out of the product.
I was talking to some of the other participants about a particular project they were involved it. He was involved in trying to deploy SharePoint as a fault tolerant system, and I was running down what he needed to do. We noticed that we were attracting a lot of attention from the leader types. You know, they are the guys in the button up shirts trying not to look lost in the sea of geeks. After a bit, the managers started to ask about how they could go about hiring the right people to set up their SharePoint environments "right." The first thing I said was that to set up their SharePoint environments "right," they needed to spend some serious money. In my experience, SharePoint needs a dedicated cross-functional team in order to be successfully deployed and maintained. The word that really stuck in the manager's craw is "dedicated." Even after seeing all of what SharePoint can do, they still believed that there would not be enough work for dedicated staff. This just isn't true. At any company were there is not dedicated SharePoint staff, immediate problems start to pop up, mostly surrounding the direction of the product, and what it can do. If staff is not dedicated, there is no incentive for an individual to study the features of SharePoint, and find out how it can be best used in the company. There is no one to support the product, leaving the end users wondering how to use it. Essentially, if you don't have dedicated staff, you are throwing the product down the tubes, and dooming your deployment for failure.
As to the hiring question... This spawned a long and interesting conversation about how many people were needed, getting input from the tech side, me, and the business side, them. All in all, those that accepted the fact that they need dedicated staff saw value in the team that I suggested.
In my ideal deployment, and this means ANY deployment, from one server to 10,000, you are going to need four roles; Architect, Administrator, Designer, and Developer. The most important, most senior, and most critical is the Architect role. This person will lead the team, develop the overall vision of the deployment, be the chief evangelist, and mentor the other roles. As you can imagine, this role is also the most difficult to hire.
Architect
This should be the first person that is hired, and should do the hiring for the rest of the team. This is a special person, because they need to have a split IT personality. In that I mean that they need to have experience with software development, and systems administration. It helps if they also have some Network Engineering in their background as well. What I mean by software development experience, is that they need to have a firm grasp of OOP, the .NET Framework, and modern design principals. They need to have written code as a developer on a software team. A person who has written code, but as a one project, one programmer shop is not your ideal candidate, as these developers often have a tough time leading a team of people.
They need to have designed and written WCF services, web services, and windows services. They need to know the role that each play, and how to integrate them in to a cohesive SOA. After all that... They need to have a good grasp of the SharePoint API, and they need to have written and deployed the major pieces involved in SharePoint development. What major pieces? Web parts, timer jobs, site definitions, and workflows. They need to know what each part does and what problems each solves.
The Architect should be able to speak to the database staff about indexes, backups, and SharePoint database architecture. They should also have a good grasp of what Remote BLOB storage is and when it is a good idea. They should be able to present this to the database staff.
On the other side of the IT fence, the Architect needs to know how SharePoint is installed, configured, deployed, and maintained. In other words, this person needs to have spent time as a professional SharePoint Administrator. As an administrator this person should have handled at least one major farm migration. This will ensure that they know what is involved in a migration, and that they have all of the lessons learned from that migration. It also ensures that they have been involved in SharePoint long enough to have seen where Microsoft has come with the product, and have some idea on where Microsoft is going with the product.
They need to have planed for and executed disaster recovery plans with SharePoint, and should be very comfortable with recovery scenarios, from a total loss of the farm, to the loss of a single file.
They should be well versed on search. How SharePoint does it, what the limitations of the Out Of the Box search features are, and when it is a good idea to put FAST Search in. They should know how to configure search so that it will return the proper results.
They also need to be a very well rounded IT person. They should know about the different methods on how to make SQL redundant, they should know how to load balance a web server, they should know what LDAP is, and what a good Active Directory design consists of and how it will impact the SharePoint deployment.
With all of this experience, it will be very difficult to interview for this position. You have to accept that the SharePoint stuff you will have to simply ask about and hope that they give you a straight answer. You are an IT manager, so hopefully you have some skill in the area of bullshit detection... If you have development staff, bring in a developer to aid in the interview. You will get a good grasp of their development skills from your trusted developer. Also bring in one of your Systems Engineers to find out what they know about AD and other Windows related services. If you have web staff, bring one in to discuss web topics. Your trusted staff should be able to give a good rundown on the candidate's general skill. From this you should be able to judge if the candidate is being truthful about what is on their resume.
Here are some of the qualities that I think that an Architect should have personally:
- Passionate about SharePoint, this should be evident in the interview.
- Passionate about IT in general.
- They should have some decent social skills. They will end up being a cheerleader and evangelist for SharePoint and its features as well as effectively lead the SharePoint team. Thus, they have to be able to communicate effectively with other humans.
With all of the technical skill we are asking for, this particular feature will be some of the hardest to meet... - They should be worried with improving their skills. They will ask about training and conference budgets.
With all of the above, you must realize that this person will not come cheap. This kind of skill comes at a premium, and you have to giver proper incentive for them to stay. The good news it that you can save money on the other members of the team.
Administrator
The Administrator position is going to be easier to find. You can ask for some SharePoint administration experience, but it really isn't required, especially if you want to save some money on this position. In a perfect world, this position will have about 2 years experience with SharePoint as an IT pro.
The necessary skills, in my opinion, are going to center around, in order of importance, IIS, PowerShell, software deployment, Windows, and experience supporting "N" tier applications. SharePoint experience would fit somewhere between Windows and supporting "N" tier applications.
IIS is the key in this position, because SharePoint is a .NET program hosted in IIS. Without a firm grasp on how IIS works, how applications are hosted, how WAS works, the administrator will fall flat on his face when the fit hits the shan. SharePoint deals heavily in Web Services and WCF and if the administrator has never supported those two things in IIS, they will be baffled on why the sections hosting the different technologies use the same authentication, but have different settings in IIS. Without web experience, the critical difference between a web application and a web site will trip them up. These things are vital to the SharePoint farm.
I would like this person to be up on the latest load balancing techniques so that they can put in to practice the load balancing methods that the Architect selects for the deployment, but this is not necessary and it can be something that the Architect mentors the Administrator on.
Experience with PowerShell is absolutely vital. Much of SharePoint administration is done through PowerShell, and many tasks can be automated with PowerShell. Being only one person, the Administrator who only uses Central Administration can only do so much. The Administrator who automates and scripts tasks multiplies their worth to the company, by being able to clone themselves many times over. Also, many tasks need to be handled off hours, the stupid Administrator stays late, or remotes in from home to complete these tasks via Central Administration. The smart, savvy Administrator, the one you want to hire, scripts all off hour tasks and has the script send him email confirmations of task completion or failure. No muss no fuss. An Administrator that automates the most common tasks also builds in automatic redundancy for themselves and has more time to focus on interesting and important work, R&D, and preventative maintenance. The administrator who does not script is constantly putting out fires, repeating the same tasks over and over, and never seems to have any time to R&D and do anything preventative.
As the developers will be handing the Administrator their code to deploy, it is a good idea to look for an IT Pro with experience in deploying software. Again, you want to see this person insist on scripted deployments, as well as packaged solutions. It makes their job easier, and makes a solid repeatable, predictable deployment the rule rather than the exception.
Supporting "N" tier applications forces the Administrator to always be thinking about what service is calling what. It also will mean that the candidate knows about authentication methods that can handle multi-server hops, or what must happen so that authentication methods that can not multi-hop on their own make those vital hops.
Developer
Again, it is not vital that the Developer have SharePoint development experience. It is vital, however, that the Developer have .NET web development experience. From the developer standpoint, SharePoint is just another API to call. Take away the funky deployment, and SharePoint development is just like any other development, inherit a base class, and implement a method. A week training class will get the Developer up to speed on SharePoint development. After that the Architect will be able to mentor them and guide them to become SharePoint developers.
What we do want out of a developer is a deep sense of curiosity. We want them to want to know why things work the way that they do, and once they know that, they should wonder how they can manipulate those things to fit what the business wants to do.
Designer
The most common flaw that very technical people have is that they have no eye for the aesthetic. Their art is in their code, or in how smoothly their servers run. Unfortunately, no matter how brilliant the code behind the site may be, if it is not pleasing to the eye, or if the user experience is bad, the deployment will fail. This is where the Designer comes in. The designer is a person who should be able to design functional, pretty, web sites. I also like my designer to be experts in the client side scripting languages that make their visions possible. JavaScript, JQuery, CSS, Flash, and Silverlight should be on the Designer's resume along with the ability to work with technical people. In my opinion the designer should be able to create a UI, then hand that UI off to the developer to wire up the functionality. In other words the Designer creates the button and puts it on the page, the Developer takes over at the mouse click.
It is not required that the Designer know about SharePoint. SharePoint experience is good, but it is far from the most vital thing you are looking for.
DBA
This last position is not listed above on my three position team list because this position does not need to be 100% dedicated to SharePoint. SharePoint handles most of the database work all on its own, with as little human interaction as possible. BUT since a major part of the SharePoint functionality depends on the database it is important to have a DBA that can be the "go-to" person with SharePoint team issues. It will be up to the DBA and the Architect to make the redundancy decisions with regards to the SQL farm. If the Developer needs to hit an external database for some reason, the DBA is who they go to to get permissions and other things in line. When the Administrator is setting up Business Intelligence, they will need the DBA to create data cubes in Analysis Services.
With these positions filled, your SharePoint deployment is set up for success. SharePoint is a unique product, and not one that can simply be thrown in to an environment. It needs dedicated people to support and maintain it so that you can get the most out of the product.
Tuesday, August 9, 2011
Microsoft Comes Calling
I have been ignoring this blog... I know... I start to write something then I get busy and well...
Anyway, I get calls and emails from recruiters all of the time. Most are for consulting jobs here and there, all require me to move somewhere, sometimes for a three month contract. No thanks. I get these contacts because I try to keep my resume and job information updated on the Internet sites. It keeps the head-hunters informed on what I am doing, and the occasional call or email for the one off silly contract here and there is a price that I pay.
The reason I do such things is for the rare occasions that a good legitimate opportunity comes my way. I found my last job this way, and now something very interesting has come my way.... A recruiter from Microsoft has given me a call. I have to admit that I have always been in awe of the Redmond company. Despite their shortcomings they have been one of the most innovative and influential companies in human history. Getting a call from the recruiter was a big deal for me.
After the initial shock wore off, I reminded myself that Microsoft is just another company, and the opportunity, while lucrative, is just another opportunity. I need to evaluate the company and the opportunity objectively and with an open mind. I have to approach their interviews with the same confidence that I would any other position.
The big difference in approaching this interview process as opposed to most interviews that I do is that the interviewers will be as or more technically sound than I am with the SharePoint line of products. Most interviews I do, the interviewer has a basic understanding of the product and thinks they know what it can do for them. I come in and, during the interview, kind of give them a rundown of what SharePoint can actually do, and let them know if the product will work for them.
In this case, the people I will interview with will not only know the product, they will know where the company wants to take it, and will have had a hand in bringing the product to where it is today.
At any rate, I am simply in the phone screen stages of the interview process. I have not been asked to Redmond, I have not talked with anyone other than the recruiter. I will be speaking with the hiring manager soon, and from there, who knows? It is an interesting opportunity, and I look forward to the process, IF the hiring manager likes me well enough to bring me in. I have heard many horror stories about Microsoft interviews, so I hope that they will be gentle with me. I will post my experiences... that is if I get an interview...
Anyway, I get calls and emails from recruiters all of the time. Most are for consulting jobs here and there, all require me to move somewhere, sometimes for a three month contract. No thanks. I get these contacts because I try to keep my resume and job information updated on the Internet sites. It keeps the head-hunters informed on what I am doing, and the occasional call or email for the one off silly contract here and there is a price that I pay.
The reason I do such things is for the rare occasions that a good legitimate opportunity comes my way. I found my last job this way, and now something very interesting has come my way.... A recruiter from Microsoft has given me a call. I have to admit that I have always been in awe of the Redmond company. Despite their shortcomings they have been one of the most innovative and influential companies in human history. Getting a call from the recruiter was a big deal for me.
After the initial shock wore off, I reminded myself that Microsoft is just another company, and the opportunity, while lucrative, is just another opportunity. I need to evaluate the company and the opportunity objectively and with an open mind. I have to approach their interviews with the same confidence that I would any other position.
The big difference in approaching this interview process as opposed to most interviews that I do is that the interviewers will be as or more technically sound than I am with the SharePoint line of products. Most interviews I do, the interviewer has a basic understanding of the product and thinks they know what it can do for them. I come in and, during the interview, kind of give them a rundown of what SharePoint can actually do, and let them know if the product will work for them.
In this case, the people I will interview with will not only know the product, they will know where the company wants to take it, and will have had a hand in bringing the product to where it is today.
At any rate, I am simply in the phone screen stages of the interview process. I have not been asked to Redmond, I have not talked with anyone other than the recruiter. I will be speaking with the hiring manager soon, and from there, who knows? It is an interesting opportunity, and I look forward to the process, IF the hiring manager likes me well enough to bring me in. I have heard many horror stories about Microsoft interviews, so I hope that they will be gentle with me. I will post my experiences... that is if I get an interview...
Tuesday, February 8, 2011
Adding the SharePoint Snap In to PowerShell
What's the first step? If you are using the ISE, and you want to have the scripts excited from any PowerShell environment:
Add-PSSnapin Microsoft.SharePoint.PowerShell
This line adds the SharePoint snapin and makes any PowerShell console the same as the SharePoint Management Console.
If you want to get cute you can add the following code to see if the SharePoint snapin is available, and throw a friendly error message if it is not:
$snapin = Get-PSSnapin | Where-Object{$_.Name -eq 'Microsoft.SharePoint.PowerShell'}
if($snapin -eq $null)
{
Write-Output('SharePoint snapin does not exist on this server')
}else{
Add-PSSnapin Microsoft.SharePoint.PowerShell
}
As long as you know the namespace of the PowerShell snap in that you want to add, the above code will work to add it simply replace the SharePoint snapin namespace (Microsoft.SharePoint.PowerShell) with the namespace of your snap in.
Add-PSSnapin Microsoft.SharePoint.PowerShell
This line adds the SharePoint snapin and makes any PowerShell console the same as the SharePoint Management Console.
If you want to get cute you can add the following code to see if the SharePoint snapin is available, and throw a friendly error message if it is not:
$snapin = Get-PSSnapin | Where-Object{$_.Name -eq 'Microsoft.SharePoint.PowerShell'}
if($snapin -eq $null)
{
Write-Output('SharePoint snapin does not exist on this server')
}else{
Add-PSSnapin Microsoft.SharePoint.PowerShell
}
As long as you know the namespace of the PowerShell snap in that you want to add, the above code will work to add it simply replace the SharePoint snapin namespace (Microsoft.SharePoint.PowerShell) with the namespace of your snap in.
Monday, February 7, 2011
Windows Server 2008 R2 High DNS Memory Usage
I was messing around with the Desktop Experience on my Windows Server 2008 R2 server and decided that I wanted to use one of the gadgets that I found useful with Windows 7. The gadget shows all of the core processor usage and the memory usage on the server.
This was a domain controller in my R&D farm, it is also my Hyper-V host so I kind of use it as a workstation as well. Don't judge me...
I installed it and found that my memory usage was abnormally high. Investigating, I opened Task Manager and found that DNS was eating up about 35MB per core. What the??? DNS should be nearly non existent. So I started to do some checking.
I hooked up my handy dandy Colasoft trace tool and found that I got a ton of errors when trying to connect to my ISP's DNS. Something about wrong format, more specifically "Additional Record: of type OPT on class Unknown DNSClass". Failure after failure after failure. It was literally like my DNS service was caught in some sort of infinite loop. What is this noise?
I found out that Microsoft was trying to be proactive with Server 2008 R2, and, by default, they enabled a new DNS format that hasn't quite yet been adopted by everybody yet. Like IP V6, this format, EDNS, is not yet everywhere. Bad news for me, because it was causing me pain.
I really don't have a whole lot of experience with DNS, other than adding records and whatnot, so how to disable this EDNS?
I found on TechNet there is a little tool, dnscmd, that will do the trick. So, all I did to disable it was to run dnscmd /config /EnableEDnsProbes 0
Immediately, my memory dropped from 35MB per core to about 2MB total. ColaSoft reported no new format errors. For now, it seems as if EDNS is not yet ready for the real world.
This was a domain controller in my R&D farm, it is also my Hyper-V host so I kind of use it as a workstation as well. Don't judge me...
I installed it and found that my memory usage was abnormally high. Investigating, I opened Task Manager and found that DNS was eating up about 35MB per core. What the??? DNS should be nearly non existent. So I started to do some checking.
I hooked up my handy dandy Colasoft trace tool and found that I got a ton of errors when trying to connect to my ISP's DNS. Something about wrong format, more specifically "Additional Record: of type OPT on class Unknown DNSClass". Failure after failure after failure. It was literally like my DNS service was caught in some sort of infinite loop. What is this noise?
I found out that Microsoft was trying to be proactive with Server 2008 R2, and, by default, they enabled a new DNS format that hasn't quite yet been adopted by everybody yet. Like IP V6, this format, EDNS, is not yet everywhere. Bad news for me, because it was causing me pain.
I really don't have a whole lot of experience with DNS, other than adding records and whatnot, so how to disable this EDNS?
I found on TechNet there is a little tool, dnscmd, that will do the trick. So, all I did to disable it was to run dnscmd /config /EnableEDnsProbes 0
Immediately, my memory dropped from 35MB per core to about 2MB total. ColaSoft reported no new format errors. For now, it seems as if EDNS is not yet ready for the real world.
Tuesday, January 11, 2011
Lots of VMs To Create In Hyper V? Sysprep!
Unless you are only doing one or two virtual machines with Windows Server 2008 R2 in Hyper V, or any virtualization software or Windows OS for that mater, you will want to save yourself some configuration time by creating an image of the OS you will be using. Windows gives us a very easy utility to do this called sysprep. It is found in the Windows directory on your system drive under System32\sysprep.
Since I do a lot of work with SharePoint and all of its related systems, I create several images so that I can quickly create a server based on what I need at the time. First I create a "base" server image. This is the generic install of Windows, no Roles installed. This gives me an image that I can use for any custom purpose. One thing that you MUST do first is to run Windows Update. You do not want to waste time on each VM getting it up to date. Do this first, then use sysprep to create your image.
After making an image of this disk, I will use the image to create a new server and then add the specific roles that will make it in to a generic image of the server and role that I want to have on hand. I always create an image of a server with IIS, and the latest versions of the .NET framework.
For technical reference, Microsoft has a page for the command line options. You could use the UI, but... I don't trust it. The line that I use is the following:
sysprep /oobe /generalize /quiet /shutdown
This removes all of the security information that is created when the server is first installed, and will put the server state in to the welcome mode to prompt you for information when you start up the server the first time.
From here copy the .vhd file somewhere safe. This is the generic disk master that you will create all of your new VM with. Be sure to name the file well. I like to name it with the OS, the role, then the last time I ran Windows Update. When updating gets to be too much of a pain after the creation of a VM, I will create a new image.
When you need a VM you will make a copy of this file, move the new file in to your .vhd directory and attach your VM to this new .vhd file.
Of course, there are more and more things you can do with automated deployment. Microsoft even has a very interesting program and tool kit that you can download and use to create all sorts of answer files and what not for large unattended image installs.
Since I do a lot of work with SharePoint and all of its related systems, I create several images so that I can quickly create a server based on what I need at the time. First I create a "base" server image. This is the generic install of Windows, no Roles installed. This gives me an image that I can use for any custom purpose. One thing that you MUST do first is to run Windows Update. You do not want to waste time on each VM getting it up to date. Do this first, then use sysprep to create your image.
After making an image of this disk, I will use the image to create a new server and then add the specific roles that will make it in to a generic image of the server and role that I want to have on hand. I always create an image of a server with IIS, and the latest versions of the .NET framework.
For technical reference, Microsoft has a page for the command line options. You could use the UI, but... I don't trust it. The line that I use is the following:
sysprep /oobe /generalize /quiet /shutdown
This removes all of the security information that is created when the server is first installed, and will put the server state in to the welcome mode to prompt you for information when you start up the server the first time.
From here copy the .vhd file somewhere safe. This is the generic disk master that you will create all of your new VM with. Be sure to name the file well. I like to name it with the OS, the role, then the last time I ran Windows Update. When updating gets to be too much of a pain after the creation of a VM, I will create a new image.
When you need a VM you will make a copy of this file, move the new file in to your .vhd directory and attach your VM to this new .vhd file.
Of course, there are more and more things you can do with automated deployment. Microsoft even has a very interesting program and tool kit that you can download and use to create all sorts of answer files and what not for large unattended image installs.
Wednesday, December 22, 2010
Reset Domain Admin Password
I had to change my admin password on my development domain recently... Then promptly forgot it. How do you over come this? I thought that I would have to reinstall Windows on my DC, and redo all of my domain work. Turns out there is a hack.
First to make this solution work you need to have a local account that has admin rights to the OS. This can be the built in Administrator user that is created on install, but if you are like most people that account has been disabled. If you have no local accounts active with admin access, you are screwed. Go find some third party hackerware that will hack your domain and leave your vulnerable to any attack the hackerware wants to put on.
Anyway I always create an account that is a local admin on my servers for various reasons. This account is not named administrator and is set up according to best practices. So what do?
First you need to get out your Windows Server 2008 R2 DVD. You boot to this disk and select the repair option.
You are then given several options. You want to click on the Command Prompt option.
Things get slightly tricky here, because it is ambiguous what your drives are called. On a physical server, the C drive is most likely C, but if you are dealing with a HyperV or a VMWare server, C just might not be C. You need to find your OS dive and navigate to your Windows\System32 directory.
Here you will need to do some trickery. You need to be able to get to the command prompt from the log in screen when you get back to normal mode. So we have to do some fun stuff in order to get this to happen. So... When you look at your log on screen what do you have to work with? You have the two text boxes, the switch user button, the submit button, and (ta da!!) the Ease of Access button. We need to rename the command prompt application to the Ease of Access application, so that when we press the Ease of Access button on the log in screen the command prompt opens.
So from your command prompt in the recovery console rename the utilman.exe to utilman.exe.bak and then rename cmd.exe to utilman.exe. Reboot
When you get to the log on screen, simply click on the Ease of Access button. That will launch the command prompt. From the prompt type "user administrator NewPass123" That's it! Log in now with your new password.
First to make this solution work you need to have a local account that has admin rights to the OS. This can be the built in Administrator user that is created on install, but if you are like most people that account has been disabled. If you have no local accounts active with admin access, you are screwed. Go find some third party hackerware that will hack your domain and leave your vulnerable to any attack the hackerware wants to put on.
Anyway I always create an account that is a local admin on my servers for various reasons. This account is not named administrator and is set up according to best practices. So what do?
First you need to get out your Windows Server 2008 R2 DVD. You boot to this disk and select the repair option.
You are then given several options. You want to click on the Command Prompt option.
Things get slightly tricky here, because it is ambiguous what your drives are called. On a physical server, the C drive is most likely C, but if you are dealing with a HyperV or a VMWare server, C just might not be C. You need to find your OS dive and navigate to your Windows\System32 directory.
Here you will need to do some trickery. You need to be able to get to the command prompt from the log in screen when you get back to normal mode. So we have to do some fun stuff in order to get this to happen. So... When you look at your log on screen what do you have to work with? You have the two text boxes, the switch user button, the submit button, and (ta da!!) the Ease of Access button. We need to rename the command prompt application to the Ease of Access application, so that when we press the Ease of Access button on the log in screen the command prompt opens.
So from your command prompt in the recovery console rename the utilman.exe to utilman.exe.bak and then rename cmd.exe to utilman.exe. Reboot
When you get to the log on screen, simply click on the Ease of Access button. That will launch the command prompt. From the prompt type "user administrator NewPass123" That's it! Log in now with your new password.
Subscribe to:
Posts (Atom)