This is a community list of Known Issues for TechNet Wiki. As issues get fixed, we will move them to the Fixed Issues section.
If your issue is more like a Feature Request, then add it to the Feature Requests for TechNet and MSDN Profiles and Social Platform Tools.
If you are facing a performance issue on TechNet Wiki (slow loading or error messages when you create an article, edit an article, add/edit a tag, or leave a comment), then go here: Report Wiki Performance Issues.
You can add issues to the appropriate section below, or you can discuss any issue in two ways:
When you edit an article with IE and select the HTML editor, you have a Find button, which includes Find and Replace functionality. This is not available if you edit the article with Firefox. This makes it difficult to fix TOC and color issues using Firefox. You cannot search for "<h" in the HTML to find headings for the TOC, or replace "rgb(0, 0, 255)" with "blue" to fix color issues.
STATUS: 08/09/2013 Still exists FireFox 23.0
STATUS: 01/03/2014 The same problem in IE 11 (no Find button in HTML editor). IE 9 has the Find button in HTML STATUS: 01/21/2017 The same problem in Edge (no Find button in HTML editor). IE 9 is the only browser version that can be used to fix TOC and RGB color issues.
When someone edits and saves an article using IE 10 or IE 11, extra line breaks (<br> tags in the HTML) get inserted. This does not happen in IE 9 or Firefox. It seems that two extra <br> tags get inserted at every line break each time you save. This was first reported December 12, 2013, in the forums, but not everyone could duplicate the problem, even on December 13. Now, as of December 16, 2013, everyone can duplicate the problem in IE 11. Some articles become twice as long when you save in IE 11. For example, this article is a mess now: Wiki: Test Issues
Forum discussion here with lots of information: http://social.technet.microsoft.com/Forums/en-US/1a2e698a-b4fa-4117-b4f7-5cecdb35e6cd/editing-wiki-adds-extra-breaks-every-time-i-save-the-article?forum=tnwiki
Glossary Wiki articles, where the terms are alphabetized, often have a Table of Contents (TOC) consisting of letters of the alphabet. When you click on a letter, you jump to entries in the glossary that begin with that letter. However, if you save such an article in Firefox, the TOC is broken. Now when you click on a letter, you get an Edit dialog instead. Nothing changes in the HTML when this happens. But when you hover over a letter with a mouse, say the letter "M", instead of the url ending in ".aspx#M", it now ends with the string "/edit.aspx#M". The fix is to save the article (with no changes) in another browser, like IE 9.
If the Wiki article has the "Return to Top" feature, similar to that used in this article, saving in Firefox will break the url. The url changes from "<title>.aspx#Top" to "<title>/edit.aspx#Top". When you click on the broken url you get an edit screen. This is very similar to issue BR3. The fix is to save the article (with no changes) in another browser, like IE 9.
Return to Top
Add additional known issues at the bottom of this section.
Search on TechNet Wiki is currently outdated. You're searching on a crawl from several months ago.
If the search results includes one more Wiki article than will fit on one page of results, there may be no link to the second page.
http://social.technet.microsoft.com/wiki/tags/rlmueller/default.aspx
This tag search results in 12 articles, but one of them (the last) does not appear in the first results (as it should):
http://social.technet.microsoft.com/wiki/tags/rlmueller/active+directory/default.aspx
http://social.technet.microsoft.com/wiki/tags/TechNet+Wiki+Portal/default.aspx
There are perhaps 2 or 3 results missing between the pages. But the following url produces 3 pages with up to 25 results per page (12 on the last page), for 62 results:
http://social.technet.microsoft.com/wiki/contents/articles/tags/TechNet+Wiki+Portal/default.aspx
Fortunately, when you click on a tag in an article, you get the second variation (with "/contents/articles/" in the url), so you get accurate results. If you attempt to manually search from the main Wiki page, you will likely use the first variation and not get all the results.
↑ Return to Top
The title you make generates a URL to the article with the title name in it. It's possible for a contributor to change a title. The old title URL redirects to the new title URL. However, if new users want to create pages with the same names as old titles, then they cannot. They will have to come up with a new title (which might break consistency standards).
When you put a title with more than 230 characters length (including spaces), the article cannot be edited anymore or even the article itself cannot be accessed.
You could see an error like Error 400, invalid page.
Sometimes, especially in lists of bullets, entire sections of content (and all the content below that section) will be automatically indented to the right.
STATUS 08/23/2012: This problem is seen often. Generally, a closing </li> tag (less often </ol> or </ul>) was missing, and the Wiki editor "fixed" the HTML by adding the missing tag, but in the wrong location. Often, the </li> tag is added after the next heading line, so the heading line is indented. Sometimes, the </li> tag is added after the next list, so the entire list is indented relative to the first list. In all cases, the fix is to move the errant </li> tag in the HTML editor. I check the last item in each list. If the last item does not have a closing </li> tag, I search for the next </li> tag, verify that it is in the wrong place, then move it to where it belongs.
STATUS: Bug verified 05/29/2013. Also using the Indentation button causes everything, including text before and after the text you are working on, to be indented. And it is very difficult to add subsequent text that is not indented.
Adding an anchor tag to a sub-header (or any text) turns it into a "go nowhere" link. Example article. This happens when you import another article with the anchor tags associated to the entire sub-header (here is an HTML example: <a name="Title1">Title 1</a>), and it also happens when you highlight the sub-header and apply the anchor to the entire sub-header.
Also, do not add anchors to your article. Instead, just use headers. At the top of your article, type the wiki code [toc] in the Design tab, and the Wiki platform will turn the text into a table of contents that lists out all the header sections, including their hierarchy (where an h2 is indented under an h1 section). Because of this TOC feature, you don't need to add anchors.
Adding a hyperlink to a full line in a bullet (where you select the whole line, including the white space to the right of the line) can ruin bullet and spacing formatting. Specifically, it turns the bullet icon blue.
TechNet Wiki Editor might not translate your table HTML code the way you want it to, especially if you are pasting from a word processor (such as Word).
STATUS: Bug verified 06/12/2013. Besides losing colors, tables can get cut off. The table in the article does not appear like the table in the editor. For example, in revision 3 of this article, Choose your MAP Toolkit Goal, the table is cut off at the right. The colors were also lost, but were restored by replacing RGB values with color names in the HTML.
Sometimes you will click Save after writing an article or completing an edit, and the article does not seem to save. It seems to be waiting indefinitely. When you click Save, you get an error message that you have already written a more recent version. This is similar to # 8 under Wiki Editor in the Fixed Issues section below.
Quite often after long waiting period there is an error message appearing. In 98% of the cases the changes made will be saved, but the editor's comment might now go to the comments section of the article.
Sometimes the TOC feature does not include all the header topics as items in the list.
At least one known reason is a bug in the Telligent platform, which has been confirmed by the developers team.
The TOC is built using the header formats in the text.
The Wiki editor adds an <a name=...> tag to the header after you save. When you use a 0 anywhere in the header, you break the formatting.
The same thing happens if the heading includes foreign characters. The issue has been confirmed for the following characters: é í ç ã. However, there are probably many others. Recently it has been reported that Farsi/Persian characters cause the heading to be ignored by the TOC feature.
Another problem is duplicate header lines in the article. The text of header lines can be duplicated in an article, and all will appear in the Table of Contents, but the links will not work. Duplicate header lines will have duplicate <a name> tags, so all of the duplicate entries in the Table of Contents will link to the same point. The fix is to modify the <a name> tags of the headers in the HTML editor to make the names of the anchor tags unique in the article.
A duplicate header line can result unexpectedly if the header has leading digits. When the <a name> tag is automatically created, any leading digits are ignored. This means that the headers "1.3 References" and "3.3 References" will have the same <a name> tag. You must edit the <a name> tags in the HTML editor to make them unique. Digits can appear anywhere else in the <a name> tag with no problems. For example, you can modify the tags as follows: <a name="References_1_3"> and <a name="References_3_3">. Note that spaces and periods must be replaced by underscores. These <a name> tags will be recognized. Of course, do not introduce zeros (the character "0").
A less common problem is when the entry in the Table of Contents includes the heading line plus all or part of the next paragraph. The cause is a missing </h1> tag (or </h2> etc). The Wiki editor adds the missing tag when you save, but in the wrong location; not at the end of the heading line, but after the next sentence or paragraph. The fix is to find the heading line in the HTML editor, verify that the terminating </h1> tag is missing (or </h2> etc), then find the next </h1> tag in the article and move it to where it belongs.
For assistance fixing a Table of Contents, refer to this Wiki article: Tips & Tricks to Fix the Wiki Article [TOC] (Table of Contents)
When you edit an article, if any colors are specified using RGB values in the HTML, the colors may be lost when the article is saved. This does not always happen, but it often does. The workaround is to replace the RGB values with the closest standard color names. This is described in this Wiki article: Wiki: Troubleshooting Color Issues in Your Wiki Articles
A problem is that the RGB system can specify over 16 million colors, but there are only about 140 color names. It is often not possible to exactly match a color specified by the RGB system. When an article is updated it is often not noticed that colors were lost. It appears that this problem has only happened since about February 22, 2013. Articles modified since that date can exhibit the problem. It would be good to know if this bug will be fixed, as it requires a lot of work in the HTML editor and the colors cannot be made to exactly match in all cases. It will also be very difficult to restore the old RGB values later if the bug is fixed.
This Wiki article was published to assist in fixing the colors in articles: Wiki: Fix Color Issues in Wiki Articles
And this VBScript program was used to select the best standard color for any RGB values (3 integers): Fix Color Issues in TechNet Wiki Articles.
STATUS: 07/11/2013. This problem happens if you edit using Internet Explorer, but not if you use Firefox or Chrome to edit the article. In fact, if you edit an article with "broken" colors in Firefox or Chrome, even if you make no changes, the colors will be restored after you save. Of course, the RGB values will remain in the HTML (which is not affected by this), so if someone else edits the article later using Internet Explorer, the colors will be lost.
07/23/2013 Confirmed Confirmed Confirmed
STATUS: 01/26/2014. Replacing RGB values with standard color names does not permanently fix the problem. When an article is later saved by someone under certain unknown conditions (perhaps browser, perhaps an add-on), the standard color names are replaced by RGB values. This has been seen several times. The colors are not lost, so the person does not know they have affected the HMTL. Then later when someone else saves the article in IE, the colors are lost.
EXAMPLE 1: Often times, you cannot add a bulleted list in (or blockquote indentation) properly. Clicking the bullet button in the Editor (or the indentation button) will indent more into the bullet than you want. Sometimes it indents multiple paragraphs. I experimented with this line, and it indented this paragraph, the "Return to Top" link under it, and the horizontal rule under that, basically everything under my H2 header. The reason is that the Editor tool buttons aren't writing to the HTML code correctly. This was verified as an IE bug!
NOTE: I have not seen this bug in the blogs.
STATUS: Verified 8/14/13. If we upgrade to the blogs editor (slated for end of summer, 2013), then we might get this fixed with the upgrade (since it's not an issue in the blogs).
EXAMPLE 2: When pasting in a numbered list, your numbers might not be translated to HTML correctly. So you might end up with 12 number three's instead of a count from 1 to 12.
STATUS: Verified 8/14/13
EXAMPLE 3: When pasting in a bulleted list from one Wiki article (or other source) into your Wiki article, you might get corruption... an extra bullet that doesn't really exist wedges itself between two bullets. It doesn't exist, meaning that you can't write on that line; you just see it (a level 1 bullet) dividing up your list. Note that this seems to only be the case if your bulleted list contains at least 3 levels in.
EXAMPLE 4: You add more bullets at the bottom of your list. These bullets might be Level 3 bullets (three levels in). You press enter to add a new bullet. And then you indent your bullet back in to Level 1. But this creates two additional bullets... your Level 1 bullet plus a new Level 2 bullet and another Level 1 bullet under that one.
EXAMPLE 4: You cannot delete or cut a whole Level 1 section of a bulleted list. You might not even be able to delete a Level 2 section. Trying to cut or delete the section results in an error, and you lost all your changes made in that editing session.
Links to TechNet Forum threads are missing the External Link icon and behave like internal Wiki links (they open in the same window). This is because the Forums use a similar URL structure as TechNet Wiki (so MSDN Forum links are marked as external).
If you add a link to an article that includes the string "[TOC]" in the title, and use the article title for display in the hyperlink (rather than the url) the string expands into a Table of Contents. See an example link in the See Also section of this article:
http://social.technet.microsoft.com/wiki/contents/articles/18419.wiki-tip-how-to-add-table-of-contents-to-the-article-in-foreign-language.aspx#comment-51937
The article being linked is this one:
http://social.technet.microsoft.com/wiki/contents/articles/12687.tips-tricks-to-fix-the-wiki-article-toc-table-of-contents.aspx
You can enter a hyperlink in the Wiki editor by entering the Wiki article title in double square brackets. For example, you can enter:
This will link to the article http://social.technet.microsoft.com/wiki/contents/articles/16757.active-directory-glossary.aspx. This method works until the title is modified. Then the link is broken. The broken link shows up in red in the article, and if the user clicks on the link, they enter an edit screen where they will create a new Wiki article if they save.
Article URLs are build like this
http://social.technet.microsoft.com/wiki/contents/articles/<article-number>.<(encoded) title>.aspx
Some - but not all - articles can be addressed using a short URL without title:
http://social.technet.microsoft.com/wiki/contents/articles/<article-number>.aspx
The behaviour of short URLs is inconsistent and depends (somehow) on the article
Expected behavior: All article support short URLs, and a short URL displays the article.
Examples: These URLs work and open the article as expected:
Lots of old wikipages contain images with HTTP URLs, these no longer work since the site has moved to HTTPS. eg. here prior to revision 11
When you click a Revision in the History tab (or compare Revisions), the tag changes appear at the top of the page. Some tags are crossed out (in red) and other tags are added (in green). Tags are shown to be crossed off and added even though that change was not made in the revision. This likely happens because the sort/reorder of the tags (into alphabetical order) accidentally registers an edit/change in the revision even though the user never made that change (it was automatically made in each revision).
When you click on a tag in the Tag Cloud (on a search results page), or when you enter the url for a tag search, the results are active articles. In this case, the url is similar to the following:
http://social.technet.microsoft.com/wiki/tags/Active+Directory/default.aspx
If, however, you click on a tag inside an article, the url is different, and the results can include recently deleted articles. For example, the same search by clicking on the tag "Active Directory" in an article would result in the following url:
http://social.technet.microsoft.com/wiki/contents/articles/tags/Active+Directory/default.aspx
When you click "Edit Tags" and add a tag, it sometimes does not show up for a long time. When you edit the article, the new tag does not show up, so you add it again.
Reported in this forum thread:
http://social.technet.microsoft.com/Forums/en-US/ab10a6c4-e955-4c9d-99ba-9ce1b13b55cc/minor-problem-with-editing-and-commenting-at-once
The problem could be associated with server problems.
If you click on the tag cloud, you get a different URL than the one you get when you click on the tag at the bottom of the Wiki article.
If a tag includes the ampersand character ,"&", it gets scrambled when someone later edits tags. For example, the tag "Q & A" gets converted into the tags "A" and "Q &" the next time tags are edited. Then these tags get converted into the tags "A", "amp", and "Q& the next time are tags edited.
This would prevent articles with no language tag, or inconsistent language tags.
At the time of a platform change, a few more articles appear where the History comments port into the article page comments. It's very difficult to repro (you'd have to change the platform to test it), and there might be specific factors (timing of when it was published versus when the platform was updated, timing of edits, whether or not any comments were in the article's page comments section). It seems to have only happened with articles that have had no other page comments, but this could be a coincidence. Happened on article with comments too, each time it happened I clicked "Save", my activity appeared there (http://social.technet.microsoft.com/wiki/) if I use another Internet Explorer windows; but the web page where I clicked "Save" timeout out with a Error (a white page that told that it wasn't able to make my request).
Adding an example picture, just happened to me while adding text there; (when I get that timeout, my comment got added into the wrong place)
Examples:
I believe this happens when the error above is shown. So, this bug is related to that error.
When you add a comment to a Wiki article there can be a long delay when you click "Post". There can be a timeout error, or you might try to refresh. You don't see your comment, so you might try again. In any case, the comment shows up later (up to 7 hours later), multiple times. This is similar to issue WE11 and is probably related. The duplicate comment is either the result of a refresh, or a second attempt to add the comment when the first attempt appears to fail. Often the user will click the comment's post button multiple times (thinking that it didn't work the first time). Each time they click Post (often three, total), another version of the same comment appears. Similarly, they leave the comment but don't know they did. So they retype the same text or they paste in the same text, thus leaving more of the same comment.
SOLUTION: The comments would need to save quickly and verify to the user that they were uploaded. Ideally, they should also be displayed almost instantly, just like the Blogs.
“ ” displays in Japanese, Chinese Traditional, Chinese Simplified, Korean, Thai and Russian localized articles. 1252 code page languages do not appear to be affected.
The appearance of these symbols depends on the request to a server. For example: http://social.technet.microsoft.com/wiki/ru-ru/contents/articles/18578.t-sql.aspx will display “ ” symbols, and http://social.technet.microsoft.com/wiki/ru-ru/contents/articles/18578.t-sql.aspx?wa=wsignin1.0 will not.
Different browsers may display “ ” symbols in different places of the article at the same time.
“ ” symbols has been observed outside the boundaries оf the TechNet Wiki.
STATUS: Still exists in Russian articles on 01/03/2015.
STATUS: Still exists оn 11/02/2013
For example, here is how a number list shows up:
But numbered lists in Farsi should be right justified, as in other text.
Some foreign characters in Japanese articles display as the double byte (DBCS) representation (for example "格") instead of the Japanese. The characters display correctly in the Edit tab, but not in the published article.
The title of the TOC is "Table of Contents" in English, even if the article language is not English. This isn't desirable in a foreign language article.
The title "Table of Contents" only appears in the English and Russian versions of the Wiki. In the other language versions (Portuguese, and Chinese), the TOC has no title.
As issues get fixed, move them here. (There is no need to add old issues here that are no longer problems. This section is just meant to be a place to move fixed issues that were once known issues in this list.)
When you use Internet Explorer 9 (IE9), line white spaces can be added anywhere in the article. We have seen them randomly added at the end of the article, after bullets, after Line Rules, and after Headers. Here's an example on this page (under "Tags").
We verified that this bug (as first mentioned in a forum thread), seems to be connected to IE9 compatibility. Also, this issue seems to happen more when you switch to the HTML tab.
STATUS: Cannot reproduce (4/17/13). Confirmed as fixed in the forum.
TechNet Wiki does not support Internet Explorer 9 (IE9).
Even though the Rule line appears in the Editor, it does not appear in the article. This seems to happen when you edit an article with Line Rules already in the article.
This issue was posted in the Wiki Forum; see: http://social.technet.microsoft.com/Forums/en-US/tnwiki/thread/9a559ae8-df20-4d91-bfc0-70a217be1416.
There is no feature to receive e-mail or RSS alerts/notifications when someone posts a comment on the article.
Unlike Wikipedia, there is no clear way of knowing when a link is external.
In the previous profile, pages that you selected as Favorites appeared in your Favorite pages section. With the new profile, there is no such section. Currently the Favorite this page link (at the bottom of every article page) does nothing.
2. Add as Friend feature does not act as expected
In the previous profile, Add as Friend added your friend to a Friends section of your profile. Because that profile version has been changed, the option to add a friend from a profile is gone. Also if you add a friend or are added as a friend, then you cannot see your friends anymore. That said, you can still add friends (even though you can't see them) by searching for their name and clicking Add as Friend under their profile name in the search results.
This is a helpful tool as a way to directly contact the person via email form. Also, you can see your activity and your friends' activity in the People tab of Recent Wiki Activity on the Wiki Home page. But this feature is rarely used by the community now that it has been removed from the Profile.
Currently you can only earn points in your profile from Forum contributions, Gallery contributions, and not Wiki contributions. A new point solution that includes Wiki contributions is currently being planned.
STATUS: Fixed on July 13th 2011, with other Profile features (like profile user cards and contribution points for blogs and annotations).
I noticed, last couple of days, there is no update on my profile and activity page. I created new article and update couple of but still not shown in the list. Also i got points from forum and even that is not showed.
The search icon in the search box is not active. (It looks like a button and acts like a button on other TechNet pages.)
The RSS for Tags link returns an empty RSS feed for any tags containing a hyphen or other punctuation.
The first person who enters the case of a tag (such as "ssAs") sets the precedence that all the tags of that combination of characters and spaces need to follow. For example, if person #1 adds the tag "ssas," then people #2-2000 who add "SSAS" are actually adding to the tag "ssas." This feature exists so that you don't end up with 8 different capitalization versions of the same tag (which is a good thing), but it still introduces a bug that while they might be consistent, the first person might not have entered the right (or best) capitalization combination (for example, they could have entered "ssAs" instead of "SSAS").
Essentially, you steal credit of the author of the article or you steal credit of the last edit. If you ever add, delete, or edit a tag in the Article tab, you will steal credit of the author (no record will exist of them having written the article), or, if there is at least one edit (two versions total), then you will remove the previous edit from the records (their edit remains, but you take credit for their edit plus the tag changes you made).
You write an article, and you go to save the article. The tags disappear. I have only seen this once so far. Add notes of any attempts here that you made to reproduce this bug (whether successes or failures). See revision 20 in this article: http://social.technet.microsoft.com/wiki/contents/articles/12031.active-directory-powershell-ad-module-properties.aspx.
If you delete an article, and when you delete it, it has a specific tag, then the article still appears in that tag's results. If you access the tag from another article or from a tag cloud, you will see the article listed on the tag results page. When you click the article, you reach a Not Found page. For example, the last article listed on this page is a deleted article: http://social.technet.microsoft.com/wiki/contents/articles/tags/Known+Issues/default.aspx.
STATUS: Cannot be duplicated May 24, 2013.
You might see no code in the Design view of the Editor, but then after you save and publish the article, you see a block of code at the top of the article.
This usually happens when pasting from a word processor (such as Word).
This seems to happen when you paste content in from other word processors. This usually gives your text random fonts and font styles such as italics.
You try saving a file and then cannot save it again because the Editor already saved it, but the Editor did not send you to the article page/tab as expected. This happens when the Editor is saving, but you think the Editor has hung. When you click Save the second time, it has already saved your content. So it gives you an error telling you that you already saved it.
WORKAROUND: Click the Article tab to make sure your saves were made. You also might want to copy text you added just in case (because if you leave after making significant changes that were not saved, you cannot get back to what you wrote).
STATUS: Same as # 11 in Wiki Editor heading
Sometimes when you click the Edit tab, the Rule Line that was previously added in a different revision does not appear in the Editor. It might be changed to white in the Editor. If you highlight the space, you will see that the line is still there. When you click Save to publish your changes (as long as you didn't delete the Rule Line), then the line still appears as black on the article page. This is a minor bug because it doesn't affect the final article page, but it is a bug and can be confusing or prompt the contributor to add another, unnecessary line rule.
Sometimes the style tags are removed by the Editor. This seems more likely when a paragraph calls a class within the style tag. This results in the content inside the tags (such as ". ClassName { margin-left:100px; }") being published on the article page, and the style doesn't take effect. This could be that the Editor isn't compatible with classes in HTML, or it could be another bug type. For more information, read this forum thread: http://social.technet.microsoft.com/Forums/en-US/tnwiki/thread/85a5ef66-35af-41e5-82c6-3a80c5b43e47
For example...
<style>.ClassName { margin-left:100px; }</style>
<p class="foo">This is a paragraph with 100px padding.</p>
Publishes with the contents of the style tag in the final article:
. ClassName { margin-left:100px; }
This is a paragraph with 100px padding.
If you use the HTML Editor to edit a Wiki article, add a comment, then click "Save" (without clicking the "Design" button to return from the HTML editor), it takes a long time to save and the comment is lost. This has happened to me several times. To avoid this problem, always click "Design" to return from the HTML editor before clicking the "Save" button.