Thursday, July 26, 2012

How to uninstall SCSM Web Portal from the server where SCSM Management Server is installed

I ended up installing SCSM and Web Portal on the same server and the Web Portal broke. This is the documented procedure to uninstall broken Web Portal from a server.
Disclaimer: These are the steps I have performed and successfully uninstalled web portal and re-installed. I am not sure whether all the steps are mandatory and required. Probably only step 4 may be required.

Before you read any further, Microsoft supported method of uninstalling Web Portal from the same server where the SCSM management server is installed is a complete uninstall of the SCSM product.
This can be accomplished using two methods:

1) run setup.exe /uninstall - If this does not work then,
2) rum msiexec /x \\...<folder where SCSM install media is kept>\ServiceManager\amd64\Setup\Server\sm.msi
  1.   Open Regedit
    a. Go to HKLM\Software\Microsoft\windows\CurrentVersion\Installer
    b. Search for "Service Manager Portal"
    c. Delete All references

2. Next go to HKLM\Software\Microsoft\System Center\2010\Service Manager\setup and delete all references to Portal

3. Next go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\223333EF9E9130B42B84BD23D7699AA2\Features and delete SMPortal

4. Open SQL management Studio and delete/rename the Sharepoint_SMPortalContent database

5. Last but not the least, rename <Drive where IIS is installed>\inetpub\wwwroot and rename the System Center Service Manager Portal to – Service Manager - Old

 6. Once you initiate the Setup.exe, you can select Web Portal and it will work just fine.

Sunday, July 8, 2012

SCCM 2012 DebugView

I found this hidden treasure of information that is not very well known in the System Center community and found it extremely handy.

Open command prompt and type:
The path where SCCM EXE is installed followed by sms:debugview e.g.

"E:\Program Files (x86)\Microsoft Configuration Manager\AdminConsole\bin\Microsoft.ConfigurationManagement.exe" sms:debugview

You can create shortcut with this command and save it on your desktop for future use.

This will give you a new option called TOOLS in the SCCM Console. This option is a view into the WMI classes, properties, and attributes. You can run queries in the console and validate the output before creating reports or scripts.

In addition, you will get an option to “Switch to Debug View” for any console. So let us see what this debug view has on offer.

You will see an additional option “Show object details” when you right click on any SCCM object such as computer object, application object, software update groups, etc.

When you click on Show Object Details, it queries WMI to access all relevant properties associated to the corresponding object and displays it in a grid view.

This will also provide extended view in the management console for collection object. I am using these capabilities now for any automation that I am doing in SCCM. I am sure you will find it handy too.

Friday, July 6, 2012

Customize the SCCM Console

Watch this space for more

ETA - July 28, 2012

Basic Understanding Citrix Xen App

Watch this space for more

ETA - 21st July, 2012

Basics of Azure

Wait this section for more

ETA - 14th August, 2012

Understanding TCP/IP Protocol Stack for your job

I don’t want to bog you down with theoretical concepts of TCP/IP stack because I have been studying those diagrams since university days and I never seem to get a hang of it. I will try to make this blog as practical as possible.
Of course, if we talk practical, I need to introduce a tool that will help me visualize TCP/IP. Netmon (or the network monitoring tool) is the tool in question that allows you to monitor the network packets between any 2 end points. It allows you to filter the packets based on any of the below mentioned protocols:

TCP/IP is a set of 5 protocols of which each protocol has a specific role to play. Think of it this ways. When we talk to each other we use a common Language to communicate to ensure the other person understands what we are saying. Similarly, devices on the network communicate with each other based on a common platform called protocols.
A device may talk to another based on one of the 5 TCP/IP protocols. Now let us understand these 5 protocols in the easiest lay man language.


Think of TCP as making a phone call to your friend. What do you do to talk to your friend over the phone:
1.       You first pick up the phone
2.       Call your friend
3.       Your friend  acknowledges your call
4.       You say HI
5.       He says Hi
6.       You start the conversation over a dedicated connection
7.       You keep checking whether your friend is listening
8.       Since you know the connection is dedicated you will talk with your friend for hours

TCP is very similar to this. I will list down its features and you will see the analogy with the above example.

1.       TCP is Connection Oriented
2.       TCP tracks data that is being sent
3.       TCP is always one end point to another i.e. it is Unicast
4.       TCP keeps checking whether the end point is listening to its messages by using a sequence number
a.       A sequence number tells TCP whether any packet is dropped or not. Think of sequence number as a serial number of packets. The first sequence number is a randomly generated number and each subsequent sequence number will have the sequence number + the size of the packet sent. E.g. if client 1 sends sequence number 22334455 with a 20 byte package. Client 2 will acknowledge, accepting sequence number: 22334455. Then Client 1 will send the next sequence number as 22334475 by adding sequence number with the size of the packet.
5.       Larger packets are sent via TCP since it is important to ascertain the sequence of the packets.


Think of IP as the GPS in your car. Whenever we are lost we look at the GPS to tell us where we need to go. It identifies whether the destination is in the city or is it in the suburbs. IP does something very similar.

Now let us look at some of the IP features and you will be able to drive a correlation.
1.       manages routing tables
2.       determines packet destination
3.       identifies whether a device is remote or local that can be done using routing tables


UDP is like going to a mall and yelling out your friend’s name. 500 people may hear that you are yelling but only 1 person may recognize you. In another situation, you may yell FIRE FIRE in the mall and everyone will understand your request, acknowledge that there is something wrong, and will run for their lives.
Some interesting facts about this form of communication are:
1.       You are not sure who all are receiving your request
2.       You cannot track who all heard you. Some people may have ignored your yelling
3.       You are talking to multiple people at the same time
4.       You can never ensure that whatever you said has been received properly by everyone.
5.       You will not have 1 hour conversations while yelling. Your talks are generally short

Now compare this with actual features of UDP

1.       Connectionless
2.       No Session
3.       No ability to track data
4.       UDP can be one end point to many
5.       UDP does not contain the sequence no.
6.       Used from Multicast and Broadcast
7.       There is no sequence number for a UDP packet.
8.       E.g. Kerberos request is generally sent via UDP
9.       Smaller packets are sent via UDP since sequence is not critical


Since we are relating these protocols with real life examples, I will try to map something for ARP as well. Assume that you are in Japan for a business deal and you don’t understand Japanese and your business partner doesn’t understand English. What would you do in this situation?

Simple – hire an interpreter. ARP is that interpreter for you. Therefore some key features of ARP are:
1.       ARP Maps IP address to MAC address
2.       On Ethernet you never talk via IP
3.       IP only helps to route from one device to another
4.       All communication primarily happens using MAC


You don’t need any real life examples for understanding ICMP since you use it so often in your daily lives that you are already an expert of ICMP. ICMP is the protocol used sending error messages and for diagnostic purposes.
We all know that the best diagnostic utility that we all use to validate whether the end point device is up and running is PING. Ping and tracert are classic examples of ICMP.
1.       Manages protocol specific communication between TCP/IP enabled devices
2.       e.g. router can send ICMP packet to a device that is having issues in TCP routing
3.       Your DNS server can send ICMP packet requests to your devices confirming its existence

Now let us see how all these protocols come together in a simple network request.
1)      Let’s say you do a dns query for from the source machine. Let’s see what happens:
a.       Your machine does an dns query for
b.      The Network Adapter setting  or the DHCP settings will point the request to the right DNS Server
c.       The DNS Server sends an ICMP request to the source machine confirming whether the DNS server can respond to your request
d.      If the DNS server can respond to the request, it returns a packet providing the A-Record (host name  of the target machine) along with the IP address suggesting that the machine IP address can be resolved and it will also mention whether the IP address is local or remote. This DNS request rides on top of UDP
e.      Two scenarios may arise here:
                                                               i.      The IP Address returned could be local - If IP address is local, source machine then sends an ARP request that broadcasts the IP address to all devices on the local network requesting devices to identify the IP address and provide the corresponding  MAC Address
1.       The interesting aspect is that once the source machine broadcasts the request, all devices in the local network receive the IP address and MAC address of the source machine
2.       Subsequently, all these devices will cache the IP address and MAC address of the source machine so that in future these devices can contact the source machine using the cached details and they don’t have to contact the DNS server going forward
                                                             ii.      The IP address returned could be remote - if IP address is remote, then source machine then sends an ARP request to the gateway of the remote IP address. It will never ARP for the IP address of the target machine if it knows that the IP Address is remote

How clients identify a packet?

·         First 6 bytes in an Ethernet packet denote the destination machine’s MAC address.
·         Let us say there is a broadcast message that is sent over UDP then the first 6 bytes will be – FF FF FF FF FF FF
·         Therefore once a machine receives a packet it will check the first 6 bytes (destination MAC address) and validate whether the packet is for the machine.
·         If the first 6 bytes belong to a machine MAC address then it is a unicast message i.e. point to point communication.
·         If the MAC address does not match then the machine will be checked for FF FF FF FF FF FF to see whether it is a broadcast. If yes, then the machine will assume that packet is meant for its consumption. It will take the packet, process it accordingly, and then forward the packet to the network since it is a broadcast.
·         Generally, if the first two bytes of the first 6 bytes of the Ethernet packet are even, it is a Unicast MAC Address. Also, the first 3 bytes of a unicast MAC address signify the manufacturer name of the network card.
·         A Multicast MAC address is configured for each application. Therefore in case of a multicast, the first 6 bytes will contain the multicast MAC address and if my machine has the registered multicast MAC address, then it will receive the packet else discard it.
·         e.g. Applications that stream audio to a group of people is a multicast.
·         PXE boots are broadcast.